From david.holmes at oracle.com Sun Jul 1 12:19:50 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 1 Jul 2018 22:19:50 +1000 Subject: [11] RFR: 8205653: test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java and RmiSslBootstrapTest.sh fail with handshake_failure In-Reply-To: <687b7dd7-5be5-cfdb-c411-2cf4a7008b12@oracle.com> References: <3e4af336-6863-4145-9dce-60b08ea64a79@default> <74fabdff-3523-49cc-5ac2-4b766c8bbb30@oracle.com> <5764f7f2-f0a7-4bf1-44dc-977953cc6cab@oracle.com> <06b1c50c-401c-4c50-9ddf-7876c0638e63@default> <687b7dd7-5be5-cfdb-c411-2cf4a7008b12@oracle.com> Message-ID: <84c24bf6-05d6-3120-6f23-2483f51e3175@oracle.com> On 29/06/2018 6:32 PM, Alan Bateman wrote: > On 29/06/2018 09:22, Sibabrata Sahoo wrote: >> May I get the approval from serviceability-dev at openjdk.java.net. >> > This a test only change to update the keystores and the list of > ciphers/protocols that the test uses. There's nothing serviceability > specific here so having a Reviewer from the security area should be okay > in the event that don't get a quick review on serviceability-dev list. +1 I certainly can't comment on any of this keystore stuff. David > -Alan From erik.gahlin at oracle.com Mon Jul 2 08:49:14 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 2 Jul 2018 10:49:14 +0200 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> Message-ID: <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> > On 29 Jun 2018, at 17:34, Se?n Coffey wrote: > > I've introduced a new test helper class in the jdk/test/lib/jfr directory to help with the dual test nature of the new tests. It's helped alot with test code duplication. > My thinking was to put things like the certificates in a separate file, i.e TestCertificates, and then have a logging test and a JFR test reuse it. One rationale for adding logging was to use it if JFR is not present. By putting the tests together, it becomes impossible to compile and test logging without having JFR. > Looked at use of @DataAmount(DataAmount.BITS) also. Not sure if it's fits. The output is displayed in units like "KiB" - not the normal when examining key lengths used in X509Certificates. i.e a 2048 bit key gets displayed as "2 KiB" - I'd prefer to keep the 2048 display version. We should not let the JMC GUI decide how units are specified. There will be other GUIs and this is the first event that uses bits, so I don?t think it is formatted that way because it was considered superior. Erik > > new webrev at: http://cr.openjdk.java.net/~coffeys/webrev.8148188.v4/webrev/ > > Regards, > Sean. > > On 28/06/18 17:59, Se?n Coffey wrote: >> Comments inline. >> >> >> On 28/06/2018 17:20, Erik Gahlin wrote: >>> It's sufficient if an event object escapes to another method (regardless if JFR is enabled or not). >>> >>> Some more feedback: >>> >>> Rename event jdk.CertChain to jdk.CertificateChain >>> Rename event jdk.X509Cert to jdk.X509Certificate >>> Rename field certChain to certificateChain. >>> Rename field serialNum to serialNumber >> all above done. >>> Rename field algId to AlgorithmicId or AlgorithmicID >> maybe "algorithm" works here also ? >>> Rename @Label("Ciphersuite") to @Label("Cipher Suite") >>> Rename @Label("Cert Chain") to @Label("Certificate Chain") >>> Rename @Label("Property Name") to "Name" or "Key" if that makes sense in the context? >>> Rename @Label("Property Value") to "Value". >>> Put events in a subcategory, i.e @Category({"Java Development Kit", "Security"}) >> done. >>> Make classes final. >> done. I had thought that the JFR mechanism required non-final classes. >>> What is the unit of the key in X509Certificate event? Bits? If that is the case, use @DataAmount(DataAmount.BITS) >> Yes - it's essentially the bit length of the keys used. Let me look into that annotation usage. >>> @Label("Serial numbers forming chain of trust") should not be a sentence. How about "Serial Numbers"? >>> >>> I think the tests are hard to read when two things are tested at the same time. It is also likely that if a test fail due to logging issues, it will be assigned to JFR because of the test name, even thought the issues is not JFR related. >> I think we're always going to have some ownership issues when tests serve a dual purpose. I still think it makes sense to keep the test logic in one place. Any failures in these tests will most likely be owned by security team. (moving the tests to security directory is also an option) >>> >>> If you want to reuse code between tests, I would put it in testlibrary. >> Let me check if there's any common patterns that could be added to the testlibary. >> >> Thanks, >> Sean. >>> >>> Erik >>> >>>> Thanks for the update Erik. By default I'm proposing that the new JFR Events and Logger be disabled. As a result the event class shouldn't escape. If performance metrics highlight an issue, we should revisit. >>>> >>>> regards, >>>> Sean. >>>> >>>> >>>> On 27/06/2018 20:57, Erik Gahlin wrote: >>>>> On 2018-06-27 21:14, Se?n Coffey wrote: >>>>>> >>>>>> >>>>>> On 27/06/2018 19:57, Xuelei Fan wrote: >>>>>>> Hi Sean, >>>>>>> >>>>>>> I may reply in several replies. >>>>>>> >>>>>>> PKIXMasterCertPathValidator.java >>>>>>> -------------------------------- >>>>>>> + CertChainEvent cce = new CertChainEvent(); >>>>>>> + if(cce.isEnabled() || EventHelper.loggingSecurity()) { >>>>>>> + String c = reversedCertList.stream() >>>>>>> + .map(x -> x.getSerialNumber().toString(16)) >>>>>>> + .collect(Collectors.joining(", ")); >>>>>>> + EventHelper.commitCertChainEvent(cce, c); >>>>>>> + } >>>>>>> >>>>>>> No matter the event or the JFR mechanism is enabled or not, the above code will create a new instance. Is the return value of cce.isEnabled() dynamically changed or static? >>>>>> This is a requirement from the JFR framework. All their event.isEnabled calls are instance methods and follow a similar pattern. The JFR team assure me that the JIT can optimize away such calls. >>>>> >>>>> The JIT will most likely not be able to optimize if the event class escapes. >>>>> >>>>> From a JFR perspective, this would be the preferred layout: >>>>> >>>>> EventA eventA= new EventA(); >>>>> eventA.value = this.value; >>>>> eventA.commit(); >>>>> >>>>> and then do logging separately: >>>>> >>>>> System.Logger.log(DEBUG, this.value) >>>>> >>>>> With this layout, the JIT will remove the allocation and dead store. >>>>> >>>>> If it is expensive to gather the data for the event, like the CertChainEvent above, the following pattern should be used. >>>>> >>>>> EventB eventB= new EventB (); >>>>> if (eventB.shouldCommit()) { >>>>> eventB.value = calculateValue(); >>>>> eventB .commit(); >>>>> } >>>>> >>>>> If JFR is not enabled, shouldCommit returns false and the JIT should be able to remove the allocation. This will be best from a performance point of view, and also in my opinion from a maintenance and readability perspective. Others may disagree. >>>>> >>>>> Erik >>>>> >>>>>>> >>>>>>> Is there a need to support both logging and JFR? I'm new to record events. I did not get the point to use both. >>>>>> I was initially hoping to concentrate on just JFR events but I got strong feedback to also consider use of Logger (esp. in cases where the jdk.jfr module is not available) >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>>>>>>> Erik, >>>>>>>> >>>>>>>> I rebased the patch with TLS v1.3 integration today. I hadn't realized how much the handshaker code had changed. Hopefully, I'll get a review from security dev team on that front. >>>>>>>> >>>>>>>> Regards the JFR semantics, I believe the edits should match majority of requests . I still have a preference for the test infra design for these new logger/JFR tests used in version 1 of webrev. I think it makes sense to keep the test functionality together - no sense in separating them out into different components IMO. Also, some of the edits to the JFR testing were made to test for the new dual log/record functionality. I might catch up with you tomorrow to see what the best arrangement would be. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> >>>>>>>> >>>>>>>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>>>>>>> Many thanks for the review comments Erik. Replies inline. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>>>>>>> Hi Sean, >>>>>>>>>> >>>>>>>>>> Some of the changes in the webrev belongs to JDK-8203629 and should be removed for clarity. >>>>>>>>>> >>>>>>>>>> Some initial comments: >>>>>>>>>> >>>>>>>>>> default.jfc, profile.jfr: >>>>>>>>>> The events should not have control="enable-exceptions". The purpose of the control attribute is so to provide parameterized configuration of events for JMC. As it is now, the security events will be enabled when a user turns on the exception events. >>>>>>>>> Makes sense. I'll remove that parameter. >>>>>>>>>> >>>>>>>>>> X509CertEvent: >>>>>>>>>> You should use milliseconds since epoch to represent a date instead of a string value, i.e. >>>>>>>>>> >>>>>>>>>> @Label("Valid From") >>>>>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>>>> public long validFrom; >>>>>>>>>> >>>>>>>>>> @Label("Valid Until") >>>>>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>>>> public long validUntil; >>>>>>>>>> >>>>>>>>> The CertificateValidity class operates on Date Object values. I'll work with the Date.getTime() method then (and update the Logger formatting) >>>>>>>>>> This following annotation adds little value >>>>>>>>>> >>>>>>>>>> @Description("Details of Security Property") >>>>>>>>>> >>>>>>>>>> I would either remove the annotation, or provide information that helps a user understand the event. For instance, what is X509, and what kind of certificates are we talking about? >>>>>>>>> Yes - that looks like the wrong Description. I'll review all of these fields. >>>>>>>>>> >>>>>>>>>> @Category("Java Application") >>>>>>>>>> >>>>>>>>>> I'm a bit worried that we will pollute the "Java Application" namespace if we add lots of JDK events in that category. We may want to add a new top level category "Java Development Kit", analogous to the "Java Virtual Machine" category, and put all security related events in subcategory, perhaps called "Security". >>>>>>>>> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>>>>>>>>> >>>>>>>>>> @Label("X509Cert") >>>>>>>>>> >>>>>>>>>> The label should be human readable name, with spaces, title cased etc. I would recommend "X.509 Certificate". In general, avoid abbreviations like "certs" and instead use labels such as "Certificate Chain". The label should be short and not a full sentence. >>>>>>>>>> >>>>>>>>>> For details see, >>>>>>>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>>>>>>> >>>>>>>>>> I think it would be good to separate testing of JFR and logging into different files / tests. I would prefer that the test name is the same as the event prefixed with "Test", i.e TestX509CertificateEvent, as this is the pattern used by other JFR tests. >>>>>>>>>> >>>>>>>>> I'll take a look at that pattern again. I've separated out the current tests into an (a) outer test to analyze the logger output and (b) the inner test which checks for JFR correctness. I did include extra logic to make sure that the EventHelper configuration was working correctly. "Events.assertField" looks very helpful. Thanks for the pointer. >>>>>>>>> >>>>>>>>> Let me take on board the suggestions below and get a new webrev out on Tuesday. >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Sean. >>>>>>>>> >>>>>>>>>> I reworked one of the tests to how I like to see it: >>>>>>>>>> >>>>>>>>>> /* >>>>>>>>>> * @test >>>>>>>>>> * @key jfr >>>>>>>>>> * @library /test/lib >>>>>>>>>> * @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >>>>>>>>>> */ >>>>>>>>>> public class TestX509CertificateEvent { >>>>>>>>>> >>>>>>>>>> private static final String CERTIFICATE_1 = "..."; >>>>>>>>>> private static final String CERTIFICATE_2 = "..."; >>>>>>>>>> >>>>>>>>>> public static void main(String... args) throws CertificateException { >>>>>>>>>> >>>>>>>>>> Recording r = new Recording(); >>>>>>>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>>>>>>> r.start(); >>>>>>>>>> >>>>>>>>>> CertificateFactory cf = CertificateFactory.getInstance("X.509"); >>>>>>>>>> cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>>>> cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>>>> >>>>>>>>>> // Make sure only one event per certificate >>>>>>>>>> cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>>>> cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>>>> >>>>>>>>>> r.stop(); >>>>>>>>>> >>>>>>>>>> List events = Events.fromRecording(r); >>>>>>>>>> Asserts.assertEquals(events.size(), 2, "Expected two X.509 Certificate events"); >>>>>>>>>> >>>>>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>>>> "RSA", 2048); >>>>>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>>>> "RSA", 2048); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> private static void assertEvent(List events, String certID, String algId, String subject, >>>>>>>>>> String issuer, String keyType, int length) throws Exception { >>>>>>>>>> >>>>>>>>>> for (RecordedEvent e : events) { >>>>>>>>>> if (e.getString("serialNumber").equals(certID)) { >>>>>>>>>> Events.assertField(e, "algId").equal(algId); >>>>>>>>>> ... >>>>>>>>>> return; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> System.out.println(events); >>>>>>>>>> throw new Exception("Could not find event with Cert ID: " + certID); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> The reworked example uses the Events.assertField method, which will give context if the assertion fails. Keeping the test simple, means it can be analyzed quickly if it fails in testing. There is no new test framework to learn, or methods to search for, and it is usually not hard to determine if the failure is product, test or infrastructure related, and what component (team) should be assigned the issue. The use of EventNames.X509Certificate means all occurrences of the event can be tracked done in an IDE using find by reference. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Erik >>>>>>>>>> >>>>>>>>>>> Following on from the recent JDK-8203629 code review, I'd like to propose enhancements on how we can record events in security libs. The introduction of the JFR libraries can give us much better ways of examining JDK actions. For the initial phase, I'm looking to enhance some key security library events in JDK 11 so that they can be either recorded to JFR, logged to a traditional logger, or both. >>>>>>>>>>> >>>>>>>>>>> Examples of how useful JFR recordings could be can be seen here : >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>>>>>>> >>>>>>>>>>> securityProp_2.png gives an example of how the JFR recording can be queried to quickly locate events of interest (in this case, code setting the jdk.tls.* Security properties). I still need to clean up the TLSEvents testcase to improve test coverage and hope to do that in coming days. >>>>>>>>>>> >>>>>>>>>>> JBS record : >>>>>>>>>>> * https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>>>>>>> >>>>>>>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From sha.jiang at oracle.com Mon Jul 2 13:02:28 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 2 Jul 2018 21:02:28 +0800 Subject: RFR[11] JDK-8205984: javax/net/ssl/compatibility/Compatibility.java failed to access port log file Message-ID: Hi, The first test case in this test doesn't release resource after reading port from the port log file, then the following cases couldn't access the log file. This patch tries to fix this issue. JBS: https://bugs.openjdk.java.net/browse/JDK-8205984 Webrev: http://cr.openjdk.java.net/~jjiang/8205984/webrev.00/ Best regards, John Jiang From xuelei.fan at oracle.com Mon Jul 2 15:11:27 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 2 Jul 2018 08:11:27 -0700 Subject: RFR[11] JDK-8205984: javax/net/ssl/compatibility/Compatibility.java failed to access port log file In-Reply-To: References: Message-ID: Looks fine to me. Thanks, Xuelei On 7/2/2018 6:02 AM, sha.jiang at oracle.com wrote: > Hi, > The first test case in this test doesn't release resource after reading > port from the port log file, > then the following cases couldn't access the log file. > This patch tries to fix this issue. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8205984 > Webrev: http://cr.openjdk.java.net/~jjiang/8205984/webrev.00/ > > Best regards, > John Jiang > From thomas.stuefe at gmail.com Tue Jul 3 10:47:41 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 3 Jul 2018 12:47:41 +0200 Subject: Failing PKCS11 tests if NSS is not installed Message-ID: Hi all, I just opened https://bugs.openjdk.java.net/browse/JDK-8206258 - the tests fail if NSS is not properly installed, which is the case on some of our test machines. I am not an expert here. The test code reads as if in this case the tests should just be skipped; however, this is not what happens - the tests fail. At some points (e.g. PKCS11Test::testNSS()) we attempt to skip the test if the NSS library directory cannot be found. However, we already fail the test - any test pulling PKCS11Test.class - because we statically initalize static final boolean badNSSVersion = getNSSVersion() >= 3.11 && getNSSVersion() < 3.12; and getNSSVersion() does not handle the "not installed" case correctly. Thanks, Thomas From prasadarao.koppula at oracle.com Tue Jul 3 12:06:14 2018 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Tue, 3 Jul 2018 05:06:14 -0700 (PDT) Subject: [8u] RFR: 8074462: Handshake messages can be strictly ordered In-Reply-To: <7f033b31-9b30-1cd6-84cc-138e76d50deb@oracle.com> References: <64436cfe-714a-494a-ba0b-352ccbf72853@default> <7f033b31-9b30-1cd6-84cc-138e76d50deb@oracle.com> Message-ID: <4c87247a-669f-4f8a-9371-e020a189ff52@default> Hi Xuelei, Thanks for quick review. All the points are valid and implemented with your suggestions. Thanks, Prasad.K -----Original Message----- From: Xuelei Fan Sent: Friday, June 29, 2018 8:17 PM To: Prasadrao Koppula ; security-dev at openjdk.java.net Subject: Re: [8u] RFR: 8074462: Handshake messages can be strictly ordered Hi Prasad, Thanks for take care of this issue. SSLEngineImpl.java ------------------ 1422 private HandshakeStatus finishHandshake() { 1423 handshaker = null; 1424 connectionState = cs_DATA; 1425 return HandshakeStatus.FINISHED; 1426 } This method are used in two places, for different purposes. It is a little bit confusing, especially the code in line 1019. I may just remove this method, and update the calling line accordingly. @@ -1024,12 +1014,11 @@: ----------------------- - handshaker = null; - receivedCCS = false; + finishHandshake(); May be sufficient to remove the "receivedCCS = false" only: handshaker = null; - receivedCCS = false; @@ -1040,15 +1029,14 @@ ----------------------- if (!writer.hasOutboundData()) { - hsStatus = HandshakeStatus.FINISHED; + hsStatus = finishHandshake(); } - handshaker = null; connectionState = cs_DATA; - receivedCCS = false; + handshaker = null; May be sufficient to remove the "receivedCCS = false" only: if (!writer.hasOutboundData()) { hsStatus = HandshakeStatus.FINISHED; } handshaker = null; connectionState = cs_DATA; - receivedCCS = false; Otherwise, looks fine to me. Xuelei On 6/29/2018 1:06 AM, Prasadrao Koppula wrote: > Could you please review the changes > > Webrev: http://cr.openjdk.java.net/~pkoppula/8074462/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8074462 > > To fix handshake message out-of-order issues, we extracted required > classes/ code from JEP 219 implementation. > > Contributed by: Sean Coffey and Prasadrao Koppula > > Thanks, > Prasad.K > From valerie.peng at oracle.com Tue Jul 3 21:03:25 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 3 Jul 2018 14:03:25 -0700 Subject: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)" Message-ID: <7c450b01-0d73-7172-c2bf-995aedfbde1b@oracle.com> Hi Tony, Would you have time to review this? Instead of doing the bounds check per block, the changes move the bounds check up one level. Bug: https://bugs.openjdk.java.net/browse/JDK-8179098 Webrev: http://cr.openjdk.java.net/~valeriep/8179098/webrev.00/ Thanks, Valerie From sha.jiang at oracle.com Wed Jul 4 05:36:08 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 4 Jul 2018 13:36:08 +0800 Subject: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found Message-ID: Hi, If NSS libs are unavailable, PKCS11 tests fail when checking NSS version. This patch tries to fix this issue. JBS: https://bugs.openjdk.java.net/browse/JDK-8206258 Webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.00/ Best regards, John Jiang From thomas.stuefe at gmail.com Wed Jul 4 06:15:02 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 4 Jul 2018 08:15:02 +0200 Subject: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found In-Reply-To: References: Message-ID: Hi, Unfortunately this is not enough. Running tests with your patch and NSS libs disabled (I renamed libsoftokn3.so) yields the following errors: sun/security/pkcs11/Secmod/AddPrivateKey.java Failed. Execution failed: `main' threw exception: java.security.ProviderException: Could not initialize NSS sun/security/pkcs11/Secmod/AddTrustedCert.java Failed. Execution failed: `main' threw exception: java.security.ProviderException: Could not initialize NSS sun/security/pkcs11/Secmod/Crypto.java Failed. Execution failed: `main' threw exception: java.security.ProviderException: Could not initialize NSS sun/security/pkcs11/Secmod/GetPrivateKey.java Failed. Execution failed: `main' threw exception: java.security.ProviderException: Could not initialize NSS sun/security/pkcs11/Secmod/JksSetPrivateKey.java Failed. Execution failed: `main' threw exception: java.security.ProviderException: Could not initialize NSS sun/security/pkcs11/Secmod/LoadKeystore.java Failed. Execution failed: `main' threw exception: java.security.ProviderException: Could not initialize NSS sun/security/pkcs11/Secmod/TestNssDbSqlite.java Failed. Execution failed: `main' threw exception: java.security.ProviderException: Could not initialize NSS sun/security/pkcs11/Secmod/TrustAnchors.java Failed. Execution failed: `main' threw exception: java.security.ProviderException: Could not initialize NSS Excerpt from TestNssDbSqlite.jtr: ----------messages:(3/98)---------- command: build TestNssDbSqlite reason: Named class compiled on demand elapsed time (seconds): 0.0 result: Passed. All files up to date #section:main ----------messages:(5/721)---------- command: main TestNssDbSqlite reason: User specified action: run main/othervm/timeout=120 TestNssDbSqlite Mode: othervm [/othervm specified] Additional options from @modules: --add-modules java.base,jdk.crypto.cryptoki --add-exports java.base/sun.security.rsa=ALL-UNNAMED --add-exports java.base/sun.security.provider=ALL-UNNAMED --add-exports java.base/sun.security.jca=ALL-UNNAMED --add-exports java.base/sun.security.tools.keytool=ALL-UNNAMED --add-exports java.base/sun.security.x509=ALL-UNNAMED --add-exports java.base/com.sun.crypto.provider=ALL-UNNAMED --add-exports jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED --add-opens jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED elapsed time (seconds): 0.445 ----------configuration:(11/604)---------- Boot Layer add modules: java.base jdk.crypto.cryptoki add exports: java.base/com.sun.crypto.provider ALL-UNNAMED java.base/sun.security.jca ALL-UNNAMED java.base/sun.security.provider ALL-UNNAMED java.base/sun.security.rsa ALL-UNNAMED java.base/sun.security.tools.keytool ALL-UNNAMED java.base/sun.security.x509 ALL-UNNAMED jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED add opens: jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED ----------System.out:(1/64)---------- Warning: can't find NSS librarys on this machine, skipping test ----------System.err:(25/1633)---------- java.security.ProviderException: Could not initialize NSS at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:218) at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) at java.base/java.security.AccessController.doPrivileged(Native Method) at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) at PKCS11Test.getSunPKCS11(PKCS11Test.java:152) at TestNssDbSqlite.initializeProvider(TestNssDbSqlite.java:121) at TestNssDbSqlite.initialize(TestNssDbSqlite.java:112) at TestNssDbSqlite.main(TestNssDbSqlite.java:67) 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:115) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: java.io.IOException: NSS initialization failed at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:234) at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:213) ... 14 more Kind Regards, Thomas On Wed, Jul 4, 2018 at 7:36 AM, wrote: > Hi, > If NSS libs are unavailable, PKCS11 tests fail when checking NSS version. > This patch tries to fix this issue. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8206258 > Webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.00/ > > Best regards, > John Jiang > From sibabrata.sahoo at oracle.com Wed Jul 4 18:36:48 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 4 Jul 2018 11:36:48 -0700 (PDT) Subject: [11] RFR: 8206355: SSLSessionImpl.getLocalPrincipal() throws NPE Message-ID: Hi, Please review the change for the following patch, JBS: https://bugs.openjdk.java.net/browse/JDK-8206355 Webrev: http://cr.openjdk.java.net/~ssahoo/8206355/webrev.00/ It fixes SSLSessionImpl.getLocalPrincipal() implementation when client side authentication is not enabled. Thanks, Siba. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Jul 4 18:42:03 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 4 Jul 2018 11:42:03 -0700 Subject: [11] RFR: 8206355: SSLSessionImpl.getLocalPrincipal() throws NPE In-Reply-To: References: Message-ID: The fix looks fine to me. Thanks, Xuelei On 7/4/2018 11:36 AM, Sibabrata Sahoo wrote: > Hi, > > Please review the change for the following patch, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8206355 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8206355/webrev.00/ > > It fixes SSLSessionImpl.getLocalPrincipal() implementation when client > side authentication is not enabled. > > Thanks, > > Siba. > From ramanand.patil at oracle.com Fri Jul 6 09:34:58 2018 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Fri, 6 Jul 2018 02:34:58 -0700 (PDT) Subject: RFR[jdk8u-dev]: 8134124: sun/security/tools/jarsigner/warnings.sh fails when using Hindi locale Message-ID: Hi all, Please review this trivial test fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8134124 Webrev: http://cr.openjdk.java.net/~rpatil/8134124/webrev.00/ The test is made locale independent now. Regards, Ramanand. From weijun.wang at oracle.com Mon Jul 9 01:53:52 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 9 Jul 2018 09:53:52 +0800 Subject: RFR[jdk8u-dev]: 8134124: sun/security/tools/jarsigner/warnings.sh fails when using Hindi locale In-Reply-To: References: Message-ID: Changes looks fine. One day we can modify it to a Java program using SecurityTools::jarsigner. Thanks Max > On Jul 6, 2018, at 5:34 PM, Ramanand Patil wrote: > > Hi all, > Please review this trivial test fix: > Bug: https://bugs.openjdk.java.net/browse/JDK-8134124 > Webrev: http://cr.openjdk.java.net/~rpatil/8134124/webrev.00/ > > The test is made locale independent now. > > Regards, > Ramanand. From weijun.wang at oracle.com Mon Jul 9 03:02:23 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 9 Jul 2018 11:02:23 +0800 Subject: [11] RFR 8198352: java.util.MissingResourceException: sun.security.util.AuthResources when trying to use com.sun.security.auth.module.UnixLoginModule Message-ID: <441796F8-BD4B-4121-8572-28DAEDA49CF5@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8198352/webrev.00/ You should not use resources in hashCode(). Thanks Max From xuelei.fan at oracle.com Mon Jul 9 03:57:27 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 8 Jul 2018 20:57:27 -0700 Subject: [11] RFR 8198352: java.util.MissingResourceException: sun.security.util.AuthResources when trying to use com.sun.security.auth.module.UnixLoginModule In-Reply-To: <441796F8-BD4B-4121-8572-28DAEDA49CF5@oracle.com> References: <441796F8-BD4B-4121-8572-28DAEDA49CF5@oracle.com> Message-ID: <71f29b4f-28a2-226f-46de-a1bb548d24f7@oracle.com> Looks fine to me. Xuelei On 7/8/2018 8:02 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8198352/webrev.00/ > > You should not use resources in hashCode(). > > Thanks > Max > From ramkumar.sunderbabu at oracle.com Mon Jul 9 06:09:20 2018 From: ramkumar.sunderbabu at oracle.com (Ramkumar Sunderbabu) Date: Sun, 8 Jul 2018 23:09:20 -0700 (PDT) Subject: [8u] RFR for backport of JDK-8175120 and JDK-8164656 Message-ID: <67c51fc4-9c30-47ea-8889-2720eacff4b6@default> Please review the backports of JDK-8175120 and JDK-8164656. Overview - Removing old tests on KDC timeout policy and replacing it with new one. Original mail threads JDK-8164656 - http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014696.html JDK-8175120 - http://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html JPRT test run - http://jdk-services.us.oracle.com/jprt/archive/2018/04/2018-04-05-005834.gtee.8193453 Thanks, Ram -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Mon Jul 9 07:38:23 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 9 Jul 2018 15:38:23 +0800 Subject: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found In-Reply-To: References: Message-ID: <905d69d6-1112-0b53-9124-f53c783fa803@oracle.com> Hi Thomas, Thanks for your testing. I'm not sure that's a reasonable case. From my view, PKCS11Test.java simply checks if the NSS library directory exists. But it looks unnecessary to check every library file. In fact, if removing libnss3 or libsoftokn3's dependencies, like libnssutil3, the test also fails. However, I still re-checked my previous solution, and made a new webrev [1]. The constant badNSSVersion in PKCS11Test.java may not be fine. The static field nss_library in PKCS11Test.java can be softokn3 or nss3 for different tests. badNSSVersion should be checked after the target nss library is determined. And this checking should happen before the real testing, especially before security manager is enabled. So, a new extension method, exactly PKCS11Test::skipTest, was introduced, and the affected tests were modified accordingly. [1] http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ Best regards, John Jiang On 2018/7/4 14:15, Thomas St?fe wrote: > Hi, > > Unfortunately this is not enough. > > Running tests with your patch and NSS libs disabled (I renamed > libsoftokn3.so) yields the following errors: > > sun/security/pkcs11/Secmod/AddPrivateKey.java > Failed. Execution > failed: `main' threw exception: java.security.ProviderException: Could > not initialize NSS > sun/security/pkcs11/Secmod/AddTrustedCert.java > Failed. Execution > failed: `main' threw exception: java.security.ProviderException: Could > not initialize NSS > sun/security/pkcs11/Secmod/Crypto.java > Failed. Execution > failed: `main' threw exception: java.security.ProviderException: Could > not initialize NSS > sun/security/pkcs11/Secmod/GetPrivateKey.java > Failed. Execution > failed: `main' threw exception: java.security.ProviderException: Could > not initialize NSS > sun/security/pkcs11/Secmod/JksSetPrivateKey.java > Failed. Execution > failed: `main' threw exception: java.security.ProviderException: Could > not initialize NSS > sun/security/pkcs11/Secmod/LoadKeystore.java > Failed. Execution > failed: `main' threw exception: java.security.ProviderException: Could > not initialize NSS > sun/security/pkcs11/Secmod/TestNssDbSqlite.java > Failed. Execution > failed: `main' threw exception: java.security.ProviderException: Could > not initialize NSS > sun/security/pkcs11/Secmod/TrustAnchors.java > Failed. Execution > failed: `main' threw exception: java.security.ProviderException: Could > not initialize NSS > > > Excerpt from TestNssDbSqlite.jtr: > > ----------messages:(3/98)---------- > command: build TestNssDbSqlite > reason: Named class compiled on demand > elapsed time (seconds): 0.0 > result: Passed. All files up to date > > #section:main > ----------messages:(5/721)---------- > command: main TestNssDbSqlite > reason: User specified action: run main/othervm/timeout=120 TestNssDbSqlite > Mode: othervm [/othervm specified] > Additional options from @modules: --add-modules > java.base,jdk.crypto.cryptoki --add-exports > java.base/sun.security.rsa=ALL-UNNAMED --add-exports > java.base/sun.security.provider=ALL-UNNAMED --add-exports > java.base/sun.security.jca=ALL-UNNAMED --add-exports > java.base/sun.security.tools.keytool=ALL-UNNAMED --add-exports > java.base/sun.security.x509=ALL-UNNAMED --add-exports > java.base/com.sun.crypto.provider=ALL-UNNAMED --add-exports > jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED --add-opens > jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED > elapsed time (seconds): 0.445 > ----------configuration:(11/604)---------- > Boot Layer > add modules: java.base jdk.crypto.cryptoki > add exports: java.base/com.sun.crypto.provider ALL-UNNAMED > java.base/sun.security.jca ALL-UNNAMED > java.base/sun.security.provider ALL-UNNAMED > java.base/sun.security.rsa ALL-UNNAMED > java.base/sun.security.tools.keytool ALL-UNNAMED > java.base/sun.security.x509 ALL-UNNAMED > jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED > add opens: jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED > > ----------System.out:(1/64)---------- > Warning: can't find NSS librarys on this machine, skipping test > ----------System.err:(25/1633)---------- > java.security.ProviderException: Could not initialize NSS > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:218) > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) > at PKCS11Test.getSunPKCS11(PKCS11Test.java:152) > at TestNssDbSqlite.initializeProvider(TestNssDbSqlite.java:121) > at TestNssDbSqlite.initialize(TestNssDbSqlite.java:112) > at TestNssDbSqlite.main(TestNssDbSqlite.java:67) > 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:115) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.io.IOException: NSS initialization failed > at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:234) > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:213) > ... 14 more > > Kind Regards, Thomas > > > On Wed, Jul 4, 2018 at 7:36 AM, wrote: >> Hi, >> If NSS libs are unavailable, PKCS11 tests fail when checking NSS version. >> This patch tries to fix this issue. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8206258 >> Webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.00/ >> >> Best regards, >> John Jiang >> From sha.jiang at oracle.com Mon Jul 9 07:39:25 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 9 Jul 2018 15:39:25 +0800 Subject: RFR[11] JDK-8203007: Address missing block coverage for ChaCha20 and Poly1305 algorithms In-Reply-To: <0d555115-1c36-9744-0541-1975eecc4303@oracle.com> References: <0d555115-1c36-9744-0541-1975eecc4303@oracle.com> Message-ID: <963d4faf-320c-b08a-3b98-ba7aecbcc022@oracle.com> Ping... John On 2018/6/25 17:50, sha.jiang at oracle.com wrote: > Hi, > This patch introduces three new tests to enhance code coverage for > ChaCha20 and Poly1305 algorithms. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8203007 > Webrev: http://cr.openjdk.java.net/~jjiang/8203007/webrev.00/ > > Best regards, > John Jiang > > From sean.coffey at oracle.com Mon Jul 9 11:13:15 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 9 Jul 2018 12:13:15 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> Message-ID: As per request from Erik, I separated the tests out into individual ones to test the JFR and Logger functionality. I introduced a new separate test for the CertificateChainEvent event also. Originally this was wrapped into the TLSHandshakeEvent test. Thanks to Erik for extra refactoring and modifications carried out to clean up the code up further. http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ This enhancement has a dependency on JDK-8203629 Regards, Sean. On 02/07/18 09:49, Erik Gahlin wrote: > >> On 29 Jun 2018, at 17:34, Se?n Coffey wrote: >> >> I've introduced a new test helper class in the jdk/test/lib/jfr directory to help with the dual test nature of the new tests. It's helped alot with test code duplication. >> > My thinking was to put things like the certificates in a separate file, i.e TestCertificates, and then have a logging test and a JFR test reuse it. > > One rationale for adding logging was to use it if JFR is not present. By putting the tests together, it becomes impossible to compile and test logging without having JFR. > >> Looked at use of @DataAmount(DataAmount.BITS) also. Not sure if it's fits. The output is displayed in units like "KiB" - not the normal when examining key lengths used in X509Certificates. i.e a 2048 bit key gets displayed as "2 KiB" - I'd prefer to keep the 2048 display version. > We should not let the JMC GUI decide how units are specified. There will be other GUIs and this is the first event that uses bits, so I don?t think it is formatted that way because it was considered superior. > > Erik > >> new webrev at: http://cr.openjdk.java.net/~coffeys/webrev.8148188.v4/webrev/ >> >> Regards, >> Sean. >> >> On 28/06/18 17:59, Se?n Coffey wrote: >>> Comments inline. >>> >>> >>> On 28/06/2018 17:20, Erik Gahlin wrote: >>>> It's sufficient if an event object escapes to another method (regardless if JFR is enabled or not). >>>> >>>> Some more feedback: >>>> >>>> Rename event jdk.CertChain to jdk.CertificateChain >>>> Rename event jdk.X509Cert to jdk.X509Certificate >>>> Rename field certChain to certificateChain. >>>> Rename field serialNum to serialNumber >>> all above done. >>>> Rename field algId to AlgorithmicId or AlgorithmicID >>> maybe "algorithm" works here also ? >>>> Rename @Label("Ciphersuite") to @Label("Cipher Suite") >>>> Rename @Label("Cert Chain") to @Label("Certificate Chain") >>>> Rename @Label("Property Name") to "Name" or "Key" if that makes sense in the context? >>>> Rename @Label("Property Value") to "Value". >>>> Put events in a subcategory, i.e @Category({"Java Development Kit", "Security"}) >>> done. >>>> Make classes final. >>> done. I had thought that the JFR mechanism required non-final classes. >>>> What is the unit of the key in X509Certificate event? Bits? If that is the case, use @DataAmount(DataAmount.BITS) >>> Yes - it's essentially the bit length of the keys used. Let me look into that annotation usage. >>>> @Label("Serial numbers forming chain of trust") should not be a sentence. How about "Serial Numbers"? >>>> >>>> I think the tests are hard to read when two things are tested at the same time. It is also likely that if a test fail due to logging issues, it will be assigned to JFR because of the test name, even thought the issues is not JFR related. >>> I think we're always going to have some ownership issues when tests serve a dual purpose. I still think it makes sense to keep the test logic in one place. Any failures in these tests will most likely be owned by security team. (moving the tests to security directory is also an option) >>>> If you want to reuse code between tests, I would put it in testlibrary. >>> Let me check if there's any common patterns that could be added to the testlibary. >>> >>> Thanks, >>> Sean. >>>> Erik >>>> >>>>> Thanks for the update Erik. By default I'm proposing that the new JFR Events and Logger be disabled. As a result the event class shouldn't escape. If performance metrics highlight an issue, we should revisit. >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> >>>>> On 27/06/2018 20:57, Erik Gahlin wrote: >>>>>> On 2018-06-27 21:14, Se?n Coffey wrote: >>>>>>> >>>>>>> On 27/06/2018 19:57, Xuelei Fan wrote: >>>>>>>> Hi Sean, >>>>>>>> >>>>>>>> I may reply in several replies. >>>>>>>> >>>>>>>> PKIXMasterCertPathValidator.java >>>>>>>> -------------------------------- >>>>>>>> + CertChainEvent cce = new CertChainEvent(); >>>>>>>> + if(cce.isEnabled() || EventHelper.loggingSecurity()) { >>>>>>>> + String c = reversedCertList.stream() >>>>>>>> + .map(x -> x.getSerialNumber().toString(16)) >>>>>>>> + .collect(Collectors.joining(", ")); >>>>>>>> + EventHelper.commitCertChainEvent(cce, c); >>>>>>>> + } >>>>>>>> >>>>>>>> No matter the event or the JFR mechanism is enabled or not, the above code will create a new instance. Is the return value of cce.isEnabled() dynamically changed or static? >>>>>>> This is a requirement from the JFR framework. All their event.isEnabled calls are instance methods and follow a similar pattern. The JFR team assure me that the JIT can optimize away such calls. >>>>>> The JIT will most likely not be able to optimize if the event class escapes. >>>>>> >>>>>> From a JFR perspective, this would be the preferred layout: >>>>>> >>>>>> EventA eventA= new EventA(); >>>>>> eventA.value = this.value; >>>>>> eventA.commit(); >>>>>> >>>>>> and then do logging separately: >>>>>> >>>>>> System.Logger.log(DEBUG, this.value) >>>>>> >>>>>> With this layout, the JIT will remove the allocation and dead store. >>>>>> >>>>>> If it is expensive to gather the data for the event, like the CertChainEvent above, the following pattern should be used. >>>>>> >>>>>> EventB eventB= new EventB (); >>>>>> if (eventB.shouldCommit()) { >>>>>> eventB.value = calculateValue(); >>>>>> eventB .commit(); >>>>>> } >>>>>> >>>>>> If JFR is not enabled, shouldCommit returns false and the JIT should be able to remove the allocation. This will be best from a performance point of view, and also in my opinion from a maintenance and readability perspective. Others may disagree. >>>>>> >>>>>> Erik >>>>>> >>>>>>>> Is there a need to support both logging and JFR? I'm new to record events. I did not get the point to use both. >>>>>>> I was initially hoping to concentrate on just JFR events but I got strong feedback to also consider use of Logger (esp. in cases where the jdk.jfr module is not available) >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>>>>>>>> Erik, >>>>>>>>> >>>>>>>>> I rebased the patch with TLS v1.3 integration today. I hadn't realized how much the handshaker code had changed. Hopefully, I'll get a review from security dev team on that front. >>>>>>>>> >>>>>>>>> Regards the JFR semantics, I believe the edits should match majority of requests . I still have a preference for the test infra design for these new logger/JFR tests used in version 1 of webrev. I think it makes sense to keep the test functionality together - no sense in separating them out into different components IMO. Also, some of the edits to the JFR testing were made to test for the new dual log/record functionality. I might catch up with you tomorrow to see what the best arrangement would be. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Sean. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>>>>>>>> Many thanks for the review comments Erik. Replies inline. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>>>>>>>> Hi Sean, >>>>>>>>>>> >>>>>>>>>>> Some of the changes in the webrev belongs to JDK-8203629 and should be removed for clarity. >>>>>>>>>>> >>>>>>>>>>> Some initial comments: >>>>>>>>>>> >>>>>>>>>>> default.jfc, profile.jfr: >>>>>>>>>>> The events should not have control="enable-exceptions". The purpose of the control attribute is so to provide parameterized configuration of events for JMC. As it is now, the security events will be enabled when a user turns on the exception events. >>>>>>>>>> Makes sense. I'll remove that parameter. >>>>>>>>>>> X509CertEvent: >>>>>>>>>>> You should use milliseconds since epoch to represent a date instead of a string value, i.e. >>>>>>>>>>> >>>>>>>>>>> @Label("Valid From") >>>>>>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>>>>> public long validFrom; >>>>>>>>>>> >>>>>>>>>>> @Label("Valid Until") >>>>>>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>>>>> public long validUntil; >>>>>>>>>>> >>>>>>>>>> The CertificateValidity class operates on Date Object values. I'll work with the Date.getTime() method then (and update the Logger formatting) >>>>>>>>>>> This following annotation adds little value >>>>>>>>>>> >>>>>>>>>>> @Description("Details of Security Property") >>>>>>>>>>> >>>>>>>>>>> I would either remove the annotation, or provide information that helps a user understand the event. For instance, what is X509, and what kind of certificates are we talking about? >>>>>>>>>> Yes - that looks like the wrong Description. I'll review all of these fields. >>>>>>>>>>> @Category("Java Application") >>>>>>>>>>> >>>>>>>>>>> I'm a bit worried that we will pollute the "Java Application" namespace if we add lots of JDK events in that category. We may want to add a new top level category "Java Development Kit", analogous to the "Java Virtual Machine" category, and put all security related events in subcategory, perhaps called "Security". >>>>>>>>>> Yes - Open to suggestions. "Security" sounds like a good suggestion. >>>>>>>>>>> @Label("X509Cert") >>>>>>>>>>> >>>>>>>>>>> The label should be human readable name, with spaces, title cased etc. I would recommend "X.509 Certificate". In general, avoid abbreviations like "certs" and instead use labels such as "Certificate Chain". The label should be short and not a full sentence. >>>>>>>>>>> >>>>>>>>>>> For details see, >>>>>>>>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>>>>>>>> >>>>>>>>>>> I think it would be good to separate testing of JFR and logging into different files / tests. I would prefer that the test name is the same as the event prefixed with "Test", i.e TestX509CertificateEvent, as this is the pattern used by other JFR tests. >>>>>>>>>>> >>>>>>>>>> I'll take a look at that pattern again. I've separated out the current tests into an (a) outer test to analyze the logger output and (b) the inner test which checks for JFR correctness. I did include extra logic to make sure that the EventHelper configuration was working correctly. "Events.assertField" looks very helpful. Thanks for the pointer. >>>>>>>>>> >>>>>>>>>> Let me take on board the suggestions below and get a new webrev out on Tuesday. >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> Sean. >>>>>>>>>> >>>>>>>>>>> I reworked one of the tests to how I like to see it: >>>>>>>>>>> >>>>>>>>>>> /* >>>>>>>>>>> * @test >>>>>>>>>>> * @key jfr >>>>>>>>>>> * @library /test/lib >>>>>>>>>>> * @run main/othervm jdk.jfr.event.security.TestX509CertificateEvent >>>>>>>>>>> */ >>>>>>>>>>> public class TestX509CertificateEvent { >>>>>>>>>>> >>>>>>>>>>> private static final String CERTIFICATE_1 = "..."; >>>>>>>>>>> private static final String CERTIFICATE_2 = "..."; >>>>>>>>>>> >>>>>>>>>>> public static void main(String... args) throws CertificateException { >>>>>>>>>>> >>>>>>>>>>> Recording r = new Recording(); >>>>>>>>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>>>>>>>> r.start(); >>>>>>>>>>> >>>>>>>>>>> CertificateFactory cf = CertificateFactory.getInstance("X.509"); >>>>>>>>>>> cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>>>>> cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>>>>> >>>>>>>>>>> // Make sure only one event per certificate >>>>>>>>>>> cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>>>>> cf.generateCertificate(new ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>>>>> >>>>>>>>>>> r.stop(); >>>>>>>>>>> >>>>>>>>>>> List events = Events.fromRecording(r); >>>>>>>>>>> Asserts.assertEquals(events.size(), 2, "Expected two X.509 Certificate events"); >>>>>>>>>>> >>>>>>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>>>>> "RSA", 2048); >>>>>>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>>>>> "RSA", 2048); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> private static void assertEvent(List events, String certID, String algId, String subject, >>>>>>>>>>> String issuer, String keyType, int length) throws Exception { >>>>>>>>>>> >>>>>>>>>>> for (RecordedEvent e : events) { >>>>>>>>>>> if (e.getString("serialNumber").equals(certID)) { >>>>>>>>>>> Events.assertField(e, "algId").equal(algId); >>>>>>>>>>> ... >>>>>>>>>>> return; >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> System.out.println(events); >>>>>>>>>>> throw new Exception("Could not find event with Cert ID: " + certID); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> The reworked example uses the Events.assertField method, which will give context if the assertion fails. Keeping the test simple, means it can be analyzed quickly if it fails in testing. There is no new test framework to learn, or methods to search for, and it is usually not hard to determine if the failure is product, test or infrastructure related, and what component (team) should be assigned the issue. The use of EventNames.X509Certificate means all occurrences of the event can be tracked done in an IDE using find by reference. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Erik >>>>>>>>>>> >>>>>>>>>>>> Following on from the recent JDK-8203629 code review, I'd like to propose enhancements on how we can record events in security libs. The introduction of the JFR libraries can give us much better ways of examining JDK actions. For the initial phase, I'm looking to enhance some key security library events in JDK 11 so that they can be either recorded to JFR, logged to a traditional logger, or both. >>>>>>>>>>>> >>>>>>>>>>>> Examples of how useful JFR recordings could be can be seen here : >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>>>>>>>> >>>>>>>>>>>> securityProp_2.png gives an example of how the JFR recording can be queried to quickly locate events of interest (in this case, code setting the jdk.tls.* Security properties). I still need to clean up the TLSEvents testcase to improve test coverage and hope to do that in coming days. >>>>>>>>>>>> >>>>>>>>>>>> JBS record : >>>>>>>>>>>> * https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>>>>>>>> >>>>>>>>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>>>>>>>> From adam.petcher at oracle.com Mon Jul 9 15:29:52 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 9 Jul 2018 11:29:52 -0400 Subject: RFR 8206915: XDH TCK issues Message-ID: <8e88159f-85c2-244c-a511-c56a1af48197@oracle.com> A couple of conformance issues were found during TCK development for XDH. Both required very small modifications to fix, so I put them under the same ticket/review in order to save time. The actual information about the issues can be found in the sub-tasks of the ticket. This fix needs to go into JDK 11, so I'm hoping a Reviewer can take a look at this soon. JBS: https://bugs.openjdk.java.net/browse/JDK-8206915 Webrev: http://cr.openjdk.java.net/~apetcher/8206915/webrev.00/ From weijun.wang at oracle.com Mon Jul 9 15:39:47 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 9 Jul 2018 23:39:47 +0800 Subject: [11] RFR 8206189: sun/security/pkcs12/EmptyPassword.java fails with Sequence tag error Message-ID: <264576B5-1358-477F-8970-0ABC145B8225@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8206189/webrev.00/ When the password is empty, some pkcs12 implementations actually use "new char[1]" internally. Therefore PKCS12KeyStore tries both "new char[0]" and "new char[1]". Occasionally, an encrypted block can be decrypted by both. If the real password is "new char[1]" but we decrypt successfully with "new char[0]", the output will be garbage and will not be parsed correctly. This fix puts the parsing code inside the retry block to "validate" the decrypted data. If it cannot be parsed correctly, the 2nd password will be retried. No new regression test, the failed test will be used to verify the fix. Thanks Max From erik.gahlin at oracle.com Mon Jul 9 16:21:22 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 9 Jul 2018 18:21:22 +0200 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> Message-ID: <5B438B82.6070601@oracle.com> Thanks Sean. Some feedback on the code in the security libraries. - We should use camel case naming convention for variables (not underscore). - Looking at sun/security/ssl/Finished.java, I wonder if it wouldn't be less code and more easy to read, if we would commit the event in a local private function and then use the EventHelper class for common functionality. Instead of: private static void recordEvent(SSLSessionImpl session) { TLSHandshakeEvent hs_event = new TLSHandshakeEvent(); if (hs_event.isEnabled() || EventHelper.loggingSecurity()) { String certIDs = ""; try { certIDs = Stream.of(session.getPeerCertificates()) .filter(c -> c instanceof X509Certificate) .map(c -> (X509Certificate) c) .map(c -> c.getSerialNumber().toString(16)) .collect(Collectors.joining(", ")); } catch (SSLPeerUnverifiedException e) { certIDs = e.getMessage(); // not verified msg } EventHelper.commitTLSHandshakeEvent(hs_event, null, session.getPeerHost(), session.getPeerPort(), session.getCipherSuite(), session.getProtocol(), certIDs); } } ... public static void commitTLSHandshakeEvent(TLSHandshakeEvent event, Instant start, String remoteHost, int remotePort, String cipherSuite, String protocolVersion, String certChain) { if (event != null && event.shouldCommit()) { event.remoteHost = remoteHost; event.remotePort = remotePort; event.cipherSuite = cipherSuite; event.protocolVersion = protocolVersion; event.certificateChain = certChain; event.commit(); } if (loggingSecurity()) { String prepend = getDurationString(start); SECURITY_LOGGER.log(LOG_LEVEL, prepend + " TLSHandshake: {0}:{1,number,#}, {2}, {3}, {4}", remoteHost, remotePort, protocolVersion, cipherSuite, certChain); } } We would do: private static void logHandshake(SSLSessionImpl s) { TLSHandshakeEvent event = new TLSHandshakeEvent(); if (event.shouldCommit()) { event.remoteHost = s.getPeerHost(); event.remotePort = s.getPeerPort(); event.cipherSuite = s.getCipherSuite(); event.protocolVersion = s.getProtocol(); event.certificateChain = EventHelper.certificateChain(s.getPeerCerticates()); event.commit(); } if (EventHelper.isLoggingSecurity()) { EventHelper.SECURITY_LOGGER.log(LOG_LEVEL, " TLSHandshake: {0}:{1,number,#}, {2}, {3}, {4}", s.getPeerHost(), s.getPeerPort(), s.getProtocol(), s.getCipherSuite(), EventHelper.certificateChain(s.getPeerCerticates())); } } ... public static String certificateChain(Certificate[] certificates) { try { return Stream.of(certificates) .filter(c -> c instanceof X509Certificate) .map(c -> (X509Certificate) c) .map(c -> c.getSerialNumber().toString(16)) .collect(Collectors.joining(", ")); } catch (SSLPeerUnverifiedException e) { return e.getMessage(); // not verified msg } } It will also meanless overhead, since only one check is needed for the log and the JIT will be able to remove the allocation. Maybe a similar pattern could be used for the other events as well? Thanks Erik > As per request from Erik, I separated the tests out into individual > ones to test the JFR and Logger functionality. I introduced a new > separate test for the CertificateChainEvent event also. Originally > this was wrapped into the TLSHandshakeEvent test. > > Thanks to Erik for extra refactoring and modifications carried out to > clean up the code up further. > > http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ > > This enhancement has a dependency on JDK-8203629 > > Regards, > Sean. > > On 02/07/18 09:49, Erik Gahlin wrote: >> >>> On 29 Jun 2018, at 17:34, Se?n Coffey wrote: >>> >>> I've introduced a new test helper class in the jdk/test/lib/jfr >>> directory to help with the dual test nature of the new tests. It's >>> helped alot with test code duplication. >>> >> My thinking was to put things like the certificates in a separate >> file, i.e TestCertificates, and then have a logging test and a JFR >> test reuse it. >> >> One rationale for adding logging was to use it if JFR is not present. >> By putting the tests together, it becomes impossible to compile and >> test logging without having JFR. >> >>> Looked at use of @DataAmount(DataAmount.BITS) also. Not sure if it's >>> fits. The output is displayed in units like "KiB" - not the normal >>> when examining key lengths used in X509Certificates. i.e a 2048 bit >>> key gets displayed as "2 KiB" - I'd prefer to keep the 2048 display >>> version. >> We should not let the JMC GUI decide how units are specified. There >> will be other GUIs and this is the first event that uses bits, so I >> don?t think it is formatted that way because it was considered superior. >> >> Erik >> >>> new webrev at: >>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v4/webrev/ >>> >>> Regards, >>> Sean. >>> >>> On 28/06/18 17:59, Se?n Coffey wrote: >>>> Comments inline. >>>> >>>> >>>> On 28/06/2018 17:20, Erik Gahlin wrote: >>>>> It's sufficient if an event object escapes to another method >>>>> (regardless if JFR is enabled or not). >>>>> >>>>> Some more feedback: >>>>> >>>>> Rename event jdk.CertChain to jdk.CertificateChain >>>>> Rename event jdk.X509Cert to jdk.X509Certificate >>>>> Rename field certChain to certificateChain. >>>>> Rename field serialNum to serialNumber >>>> all above done. >>>>> Rename field algId to AlgorithmicId or AlgorithmicID >>>> maybe "algorithm" works here also ? >>>>> Rename @Label("Ciphersuite") to @Label("Cipher Suite") >>>>> Rename @Label("Cert Chain") to @Label("Certificate Chain") >>>>> Rename @Label("Property Name") to "Name" or "Key" if that makes >>>>> sense in the context? >>>>> Rename @Label("Property Value") to "Value". >>>>> Put events in a subcategory, i.e @Category({"Java Development >>>>> Kit", "Security"}) >>>> done. >>>>> Make classes final. >>>> done. I had thought that the JFR mechanism required non-final classes. >>>>> What is the unit of the key in X509Certificate event? Bits? If >>>>> that is the case, use @DataAmount(DataAmount.BITS) >>>> Yes - it's essentially the bit length of the keys used. Let me look >>>> into that annotation usage. >>>>> @Label("Serial numbers forming chain of trust") should not be a >>>>> sentence. How about "Serial Numbers"? >>>>> >>>>> I think the tests are hard to read when two things are tested at >>>>> the same time. It is also likely that if a test fail due to >>>>> logging issues, it will be assigned to JFR because of the test >>>>> name, even thought the issues is not JFR related. >>>> I think we're always going to have some ownership issues when tests >>>> serve a dual purpose. I still think it makes sense to keep the test >>>> logic in one place. Any failures in these tests will most likely be >>>> owned by security team. (moving the tests to security directory is >>>> also an option) >>>>> If you want to reuse code between tests, I would put it in >>>>> testlibrary. >>>> Let me check if there's any common patterns that could be added to >>>> the testlibary. >>>> >>>> Thanks, >>>> Sean. >>>>> Erik >>>>> >>>>>> Thanks for the update Erik. By default I'm proposing that the new >>>>>> JFR Events and Logger be disabled. As a result the event class >>>>>> shouldn't escape. If performance metrics highlight an issue, we >>>>>> should revisit. >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> >>>>>> On 27/06/2018 20:57, Erik Gahlin wrote: >>>>>>> On 2018-06-27 21:14, Se?n Coffey wrote: >>>>>>>> >>>>>>>> On 27/06/2018 19:57, Xuelei Fan wrote: >>>>>>>>> Hi Sean, >>>>>>>>> >>>>>>>>> I may reply in several replies. >>>>>>>>> >>>>>>>>> PKIXMasterCertPathValidator.java >>>>>>>>> -------------------------------- >>>>>>>>> + CertChainEvent cce = new CertChainEvent(); >>>>>>>>> + if(cce.isEnabled() || EventHelper.loggingSecurity()) { >>>>>>>>> + String c = reversedCertList.stream() >>>>>>>>> + .map(x -> x.getSerialNumber().toString(16)) >>>>>>>>> + .collect(Collectors.joining(", ")); >>>>>>>>> + EventHelper.commitCertChainEvent(cce, c); >>>>>>>>> + } >>>>>>>>> >>>>>>>>> No matter the event or the JFR mechanism is enabled or not, >>>>>>>>> the above code will create a new instance. Is the return >>>>>>>>> value of cce.isEnabled() dynamically changed or static? >>>>>>>> This is a requirement from the JFR framework. All their >>>>>>>> event.isEnabled calls are instance methods and follow a similar >>>>>>>> pattern. The JFR team assure me that the JIT can optimize away >>>>>>>> such calls. >>>>>>> The JIT will most likely not be able to optimize if the event >>>>>>> class escapes. >>>>>>> >>>>>>> From a JFR perspective, this would be the preferred layout: >>>>>>> >>>>>>> EventA eventA= new EventA(); >>>>>>> eventA.value = this.value; >>>>>>> eventA.commit(); >>>>>>> >>>>>>> and then do logging separately: >>>>>>> >>>>>>> System.Logger.log(DEBUG, this.value) >>>>>>> >>>>>>> With this layout, the JIT will remove the allocation and dead >>>>>>> store. >>>>>>> >>>>>>> If it is expensive to gather the data for the event, like the >>>>>>> CertChainEvent above, the following pattern should be used. >>>>>>> >>>>>>> EventB eventB= new EventB (); >>>>>>> if (eventB.shouldCommit()) { >>>>>>> eventB.value = calculateValue(); >>>>>>> eventB .commit(); >>>>>>> } >>>>>>> >>>>>>> If JFR is not enabled, shouldCommit returns false and the JIT >>>>>>> should be able to remove the allocation. This will be best from >>>>>>> a performance point of view, and also in my opinion from a >>>>>>> maintenance and readability perspective. Others may disagree. >>>>>>> >>>>>>> Erik >>>>>>> >>>>>>>>> Is there a need to support both logging and JFR? I'm new to >>>>>>>>> record events. I did not get the point to use both. >>>>>>>> I was initially hoping to concentrate on just JFR events but I >>>>>>>> got strong feedback to also consider use of Logger (esp. in >>>>>>>> cases where the jdk.jfr module is not available) >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> On 6/26/2018 3:18 PM, Se?n Coffey wrote: >>>>>>>>>> Erik, >>>>>>>>>> >>>>>>>>>> I rebased the patch with TLS v1.3 integration today. I hadn't >>>>>>>>>> realized how much the handshaker code had changed. Hopefully, >>>>>>>>>> I'll get a review from security dev team on that front. >>>>>>>>>> >>>>>>>>>> Regards the JFR semantics, I believe the edits should match >>>>>>>>>> majority of requests . I still have a preference for the test >>>>>>>>>> infra design for these new logger/JFR tests used in version 1 >>>>>>>>>> of webrev. I think it makes sense to keep the test >>>>>>>>>> functionality together - no sense in separating them out into >>>>>>>>>> different components IMO. Also, some of the edits to the JFR >>>>>>>>>> testing were made to test for the new dual log/record >>>>>>>>>> functionality. I might catch up with you tomorrow to see what >>>>>>>>>> the best arrangement would be. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/ >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> Sean. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 25/06/2018 21:22, Se?n Coffey wrote: >>>>>>>>>>> Many thanks for the review comments Erik. Replies inline. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 24/06/2018 14:21, Erik Gahlin wrote: >>>>>>>>>>>> Hi Sean, >>>>>>>>>>>> >>>>>>>>>>>> Some of the changes in the webrev belongs to JDK-8203629 >>>>>>>>>>>> and should be removed for clarity. >>>>>>>>>>>> >>>>>>>>>>>> Some initial comments: >>>>>>>>>>>> >>>>>>>>>>>> default.jfc, profile.jfr: >>>>>>>>>>>> The events should not have control="enable-exceptions". The >>>>>>>>>>>> purpose of the control attribute is so to provide >>>>>>>>>>>> parameterized configuration of events for JMC. As it is >>>>>>>>>>>> now, the security events will be enabled when a user turns >>>>>>>>>>>> on the exception events. >>>>>>>>>>> Makes sense. I'll remove that parameter. >>>>>>>>>>>> X509CertEvent: >>>>>>>>>>>> You should use milliseconds since epoch to represent a date >>>>>>>>>>>> instead of a string value, i.e. >>>>>>>>>>>> >>>>>>>>>>>> @Label("Valid From") >>>>>>>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>>>>>> public long validFrom; >>>>>>>>>>>> >>>>>>>>>>>> @Label("Valid Until") >>>>>>>>>>>> @Timestamp(Timestamp.MILLISECONDS_SINCE_EPOCH) >>>>>>>>>>>> public long validUntil; >>>>>>>>>>>> >>>>>>>>>>> The CertificateValidity class operates on Date Object >>>>>>>>>>> values. I'll work with the Date.getTime() method then (and >>>>>>>>>>> update the Logger formatting) >>>>>>>>>>>> This following annotation adds little value >>>>>>>>>>>> >>>>>>>>>>>> @Description("Details of Security Property") >>>>>>>>>>>> >>>>>>>>>>>> I would either remove the annotation, or provide >>>>>>>>>>>> information that helps a user understand the event. For >>>>>>>>>>>> instance, what is X509, and what kind of certificates are >>>>>>>>>>>> we talking about? >>>>>>>>>>> Yes - that looks like the wrong Description. I'll review all >>>>>>>>>>> of these fields. >>>>>>>>>>>> @Category("Java Application") >>>>>>>>>>>> >>>>>>>>>>>> I'm a bit worried that we will pollute the "Java >>>>>>>>>>>> Application" namespace if we add lots of JDK events in that >>>>>>>>>>>> category. We may want to add a new top level category "Java >>>>>>>>>>>> Development Kit", analogous to the "Java Virtual Machine" >>>>>>>>>>>> category, and put all security related events in >>>>>>>>>>>> subcategory, perhaps called "Security". >>>>>>>>>>> Yes - Open to suggestions. "Security" sounds like a good >>>>>>>>>>> suggestion. >>>>>>>>>>>> @Label("X509Cert") >>>>>>>>>>>> >>>>>>>>>>>> The label should be human readable name, with spaces, title >>>>>>>>>>>> cased etc. I would recommend "X.509 Certificate". In >>>>>>>>>>>> general, avoid abbreviations like "certs" and instead use >>>>>>>>>>>> labels such as "Certificate Chain". The label should be >>>>>>>>>>>> short and not a full sentence. >>>>>>>>>>>> >>>>>>>>>>>> For details see, >>>>>>>>>>>> https://docs.oracle.com/javase/10/docs/api/jdk/jfr/Label.html >>>>>>>>>>>> >>>>>>>>>>>> I think it would be good to separate testing of JFR and >>>>>>>>>>>> logging into different files / tests. I would prefer that >>>>>>>>>>>> the test name is the same as the event prefixed with >>>>>>>>>>>> "Test", i.e TestX509CertificateEvent, as this is the >>>>>>>>>>>> pattern used by other JFR tests. >>>>>>>>>>>> >>>>>>>>>>> I'll take a look at that pattern again. I've separated out >>>>>>>>>>> the current tests into an (a) outer test to analyze the >>>>>>>>>>> logger output and (b) the inner test which checks for JFR >>>>>>>>>>> correctness. I did include extra logic to make sure that the >>>>>>>>>>> EventHelper configuration was working correctly. >>>>>>>>>>> "Events.assertField" looks very helpful. Thanks for the >>>>>>>>>>> pointer. >>>>>>>>>>> >>>>>>>>>>> Let me take on board the suggestions below and get a new >>>>>>>>>>> webrev out on Tuesday. >>>>>>>>>>> >>>>>>>>>>> regards, >>>>>>>>>>> Sean. >>>>>>>>>>> >>>>>>>>>>>> I reworked one of the tests to how I like to see it: >>>>>>>>>>>> >>>>>>>>>>>> /* >>>>>>>>>>>> * @test >>>>>>>>>>>> * @key jfr >>>>>>>>>>>> * @library /test/lib >>>>>>>>>>>> * @run main/othervm >>>>>>>>>>>> jdk.jfr.event.security.TestX509CertificateEvent >>>>>>>>>>>> */ >>>>>>>>>>>> public class TestX509CertificateEvent { >>>>>>>>>>>> >>>>>>>>>>>> private static final String CERTIFICATE_1 = "..."; >>>>>>>>>>>> private static final String CERTIFICATE_2 = "..."; >>>>>>>>>>>> >>>>>>>>>>>> public static void main(String... args) throws >>>>>>>>>>>> CertificateException { >>>>>>>>>>>> >>>>>>>>>>>> Recording r = new Recording(); >>>>>>>>>>>> r.enable(EventNames.X509Certificate).withoutStackTrace(); >>>>>>>>>>>> r.start(); >>>>>>>>>>>> >>>>>>>>>>>> CertificateFactory cf = >>>>>>>>>>>> CertificateFactory.getInstance("X.509"); >>>>>>>>>>>> cf.generateCertificate(new >>>>>>>>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>>>>>> cf.generateCertificate(new >>>>>>>>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>>>>>> >>>>>>>>>>>> // Make sure only one event per certificate >>>>>>>>>>>> cf.generateCertificate(new >>>>>>>>>>>> ByteArrayInputStream(CERTIFICATE_1.getBytes())); >>>>>>>>>>>> cf.generateCertificate(new >>>>>>>>>>>> ByteArrayInputStream(CERTIFICATE_2.getBytes())); >>>>>>>>>>>> >>>>>>>>>>>> r.stop(); >>>>>>>>>>>> >>>>>>>>>>>> List events = Events.fromRecording(r); >>>>>>>>>>>> Asserts.assertEquals(events.size(), 2, "Expected >>>>>>>>>>>> two X.509 Certificate events"); >>>>>>>>>>>> >>>>>>>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>>>>>> "RSA", 2048); >>>>>>>>>>>> assertEvent(events, "1000", "SHA256withRSA", >>>>>>>>>>>> "CN=SSLCertificate, O=SomeCompany", >>>>>>>>>>>> "CN=Intermediate CA Cert, O=SomeCompany", >>>>>>>>>>>> "RSA", 2048); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> private static void assertEvent(List >>>>>>>>>>>> events, String certID, String algId, String subject, >>>>>>>>>>>> String issuer, String keyType, int length) >>>>>>>>>>>> throws Exception { >>>>>>>>>>>> >>>>>>>>>>>> for (RecordedEvent e : events) { >>>>>>>>>>>> if (e.getString("serialNumber").equals(certID)) { >>>>>>>>>>>> Events.assertField(e, "algId").equal(algId); >>>>>>>>>>>> ... >>>>>>>>>>>> return; >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> System.out.println(events); >>>>>>>>>>>> throw new Exception("Could not find event with Cert >>>>>>>>>>>> ID: " + certID); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> The reworked example uses the Events.assertField method, >>>>>>>>>>>> which will give context if the assertion fails. Keeping the >>>>>>>>>>>> test simple, means it can be analyzed quickly if it fails >>>>>>>>>>>> in testing. There is no new test framework to learn, or >>>>>>>>>>>> methods to search for, and it is usually not hard to >>>>>>>>>>>> determine if the failure is product, test or infrastructure >>>>>>>>>>>> related, and what component (team) should be assigned the >>>>>>>>>>>> issue. The use of EventNames.X509Certificate means all >>>>>>>>>>>> occurrences of the event can be tracked done in an IDE >>>>>>>>>>>> using find by reference. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Erik >>>>>>>>>>>> >>>>>>>>>>>>> Following on from the recent JDK-8203629 code review, I'd >>>>>>>>>>>>> like to propose enhancements on how we can record events >>>>>>>>>>>>> in security libs. The introduction of the JFR libraries >>>>>>>>>>>>> can give us much better ways of examining JDK actions. For >>>>>>>>>>>>> the initial phase, I'm looking to enhance some key >>>>>>>>>>>>> security library events in JDK 11 so that they can be >>>>>>>>>>>>> either recorded to JFR, logged to a traditional logger, or >>>>>>>>>>>>> both. >>>>>>>>>>>>> >>>>>>>>>>>>> Examples of how useful JFR recordings could be can be seen >>>>>>>>>>>>> here : >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> securityProp_2.png gives an example of how the JFR >>>>>>>>>>>>> recording can be queried to quickly locate events of >>>>>>>>>>>>> interest (in this case, code setting the jdk.tls.* >>>>>>>>>>>>> Security properties). I still need to clean up the >>>>>>>>>>>>> TLSEvents testcase to improve test coverage and hope to do >>>>>>>>>>>>> that in coming days. >>>>>>>>>>>>> >>>>>>>>>>>>> JBS record : >>>>>>>>>>>>> * https://bugs.openjdk.java.net/browse/JDK-8148188 >>>>>>>>>>>>> >>>>>>>>>>>>> webrev : >>>>>>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ >>>>>>>>>>>>> > From sean.coffey at oracle.com Mon Jul 9 17:01:54 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 9 Jul 2018 18:01:54 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <5B438B82.6070601@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> Message-ID: <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> Erik, Thanks for reviewing. Comments inline.. On 09/07/18 17:21, Erik Gahlin wrote: > Thanks Sean. > > Some feedback on the code in the security libraries. > > - We should use camel case naming convention for variables (not > underscore). Sure. I see two offending variable names which I'll fix up. > > - Looking at sun/security/ssl/Finished.java, > > I wonder if it wouldn't be less code and more easy to read, if we > would commit the event in a local private function and then use the > EventHelper class for common functionality. I'm fine with your suggested approach. I figured that tucking the recording/logging logic away in a helper class also had benefits but I'll re-factor to your suggested style unless I hear objections. regards, Sean. From anthony.scarpino at oracle.com Mon Jul 9 22:14:02 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 9 Jul 2018 15:14:02 -0700 Subject: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)" In-Reply-To: <7c450b01-0d73-7172-c2bf-995aedfbde1b@oracle.com> References: <7c450b01-0d73-7172-c2bf-995aedfbde1b@oracle.com> Message-ID: <00057e2a-af60-7e1a-dcd0-aad329c44c94@oracle.com> On 07/03/2018 02:03 PM, Valerie Peng wrote: > Hi Tony, > > Would you have time to review this? Instead of doing the bounds check > per block, the changes move the bounds check up one level. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179098 > > Webrev: http://cr.openjdk.java.net/~valeriep/8179098/webrev.00/ > > Thanks, > Valerie ArrayUtil.java: Line 48 - It seems like your not throwing any ArrayIndexOutOfBoundsExceptions, is that intentional? The method in the try-catch seems to only throw IndexOutOfBoundsException, whole if() seems confusing to me. thanks Tony From valerie.peng at oracle.com Tue Jul 10 00:42:41 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 9 Jul 2018 17:42:41 -0700 Subject: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)" In-Reply-To: <00057e2a-af60-7e1a-dcd0-aad329c44c94@oracle.com> References: <7c450b01-0d73-7172-c2bf-995aedfbde1b@oracle.com> <00057e2a-af60-7e1a-dcd0-aad329c44c94@oracle.com> Message-ID: <44bd0db3-7854-ef83-f18b-44d02702cb9b@oracle.com> Hi Tony, The purpose of the if-block is to ensure that ArrayIndexOutOfBoundsException is thrown instead of IndexOutOfBoundsException.? Objects.checkFromIndexSize(...) API is specified to throw IndexOutOfBoundsException which is more general and can be thrown when an index of some sort (such as to an array, to a string, or to a vector) is out of range. ArrayIndexOutOfBoundsException is a subclass of IndexOutOfBoundsException and is for array index out of bounds. Thanks, Valerie On 7/9/2018 3:14 PM, Anthony Scarpino wrote: > On 07/03/2018 02:03 PM, Valerie Peng wrote: >> Hi Tony, >> >> Would you have time to review this? Instead of doing the bounds check >> per block, the changes move the bounds check up one level. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8179098 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8179098/webrev.00/ >> >> Thanks, >> Valerie > > > ArrayUtil.java: Line 48 > - It seems like your not throwing any ArrayIndexOutOfBoundsExceptions, > is that intentional? The method in the try-catch seems to only throw > IndexOutOfBoundsException, whole if() seems confusing to me. > thanks > > Tony From xuelei.fan at oracle.com Tue Jul 10 00:55:50 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 9 Jul 2018 17:55:50 -0700 Subject: RFR[11] JDK-8203007: Address missing block coverage for ChaCha20 and Poly1305 algorithms In-Reply-To: <0d555115-1c36-9744-0541-1975eecc4303@oracle.com> References: <0d555115-1c36-9744-0541-1975eecc4303@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 6/25/2018 2:50 AM, sha.jiang at oracle.com wrote: > Hi, > This patch introduces three new tests to enhance code coverage for > ChaCha20 and Poly1305 algorithms. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8203007 > Webrev: http://cr.openjdk.java.net/~jjiang/8203007/webrev.00/ > > Best regards, > John Jiang > From sha.jiang at oracle.com Tue Jul 10 09:27:04 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 10 Jul 2018 17:27:04 +0800 Subject: RFR[11] JDK-8199645: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with Connection reset Message-ID: <8b349aec-e1d9-dd03-8755-c5cf19aa2c6c@oracle.com> Hi, javax/net/ssl/SSLSession/TestEnabledProtocols.java may have some problem on sync between server and client. And it would be better to refactor this test with SSLSocketTemplate.java. Webrev: http://cr.openjdk.java.net/~jjiang/8199645/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8199645 Best regards, John Jiang From sean.coffey at oracle.com Tue Jul 10 12:50:42 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 10 Jul 2018 13:50:42 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> Message-ID: Erik, After some trial edits, I'm not so sure if moving the event & logger commit code into the class where it's used works too well after all. In the code you suggested, there's an assumption that calls such as EventHelper.certificateChain(..) are low cost. While that might be the case here, it's something we can't always assume. It's called once for the JFR operation and once for the Logger operation. That pattern multiplies itself further in other Events. i.e. set up and assign the variables for a JFR event without knowing whether they'll be needed again for the Logger call. We could work around it by setting up some local variables and re-using them in the Logger code but then, we're back to where we were. The current EventHelper design eliminates this problem and also helps to abstract the recording/logging functionality away from the functionality of the class itself. It also becomes a problem where we record events in multiple different classes (e.g. SecurityPropertyEvent). While we could leave the code in EventHelper for this case, we then have a mixed design pattern. Are you ok with leaving as is for now? A future wish might be one where JFR would handle Logger via its own framework/API in a future JDK release. I've removed the variable names using underscore. Also optimized some variable assignments in X509Impl.commitEvent(..) http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ regards, Sean. On 09/07/2018 18:01, Se?n Coffey wrote: > Erik, > > Thanks for reviewing. Comments inline.. > > On 09/07/18 17:21, Erik Gahlin wrote: >> Thanks Sean. >> >> Some feedback on the code in the security libraries. >> >> - We should use camel case naming convention for variables (not >> underscore). > Sure. I see two offending variable names which I'll fix up. >> >> - Looking at sun/security/ssl/Finished.java, >> >> I wonder if it wouldn't be less code and more easy to read, if we >> would commit the event in a local private function and then use the >> EventHelper class for common functionality. > I'm fine with your suggested approach. I figured that tucking the > recording/logging logic away in a helper class also had benefits but > I'll re-factor to your suggested style unless I hear objections. > > regards, > Sean. > From xuelei.fan at oracle.com Tue Jul 10 13:33:09 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Jul 2018 06:33:09 -0700 Subject: RFR[11] JDK-8199645: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with Connection reset In-Reply-To: <8b349aec-e1d9-dd03-8755-c5cf19aa2c6c@oracle.com> References: <8b349aec-e1d9-dd03-8755-c5cf19aa2c6c@oracle.com> Message-ID: <48e99066-11ff-3a71-29e3-d7e7466d859e@oracle.com> Looks fine to me. Please limit each line in 80 characters. Thanks, Xuelei On 7/10/2018 2:27 AM, sha.jiang at oracle.com wrote: > Hi, > javax/net/ssl/SSLSession/TestEnabledProtocols.java may have some problem > on sync between server and client. > And it would be better to refactor this test with SSLSocketTemplate.java. > > Webrev: http://cr.openjdk.java.net/~jjiang/8199645/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8199645 > > Best regards, > John Jiang > From Alan.Bateman at oracle.com Tue Jul 10 16:57:33 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Jul 2018 17:57:33 +0100 Subject: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later) In-Reply-To: References: Message-ID: Forwarding to security-dev. On 10/07/2018 17:47, Norman Maurer wrote: > Hi all, > > I just tried to run netty[1] testsuite with the latest jdk11 EA > release (21) and saw some class-cast-exception with our custom > SSLEngine implementation > > > Caused by: java.lang.ClassCastException: class > io.netty.handler.ssl.OpenSslEngine cannot be cast to class > sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine is > in unnamed module of loader 'app'; sun.security.ssl.SSLEngineImpl is > in module java.base of loader 'bootstrap') > at > java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgorithmConstraints.java:93) > at > java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:270) > at > java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141) > at > io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:237) > at > io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:621) > ... 27 more > > > This change seems to be related to: > http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea > > I think you miss an instanceof check here in SSLAlgorithmConstraints > before try to cast to SSLEngineImpl, as otherwise it will be > impossible to use custom implementations of SSLEngine (which we have > in netty) with the default TrustManagerFactory. > > Does this sound correct ? Should I open a bug-report ? > > Bye > Norman > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Tue Jul 10 17:18:31 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 10 Jul 2018 14:18:31 -0300 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Message-ID: Hi, Webrev 04 for JDK-8029661 is ready: * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.04.zip * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.04/ New: * Rebased to latest JDK revision (after TLS 1.3 merge) * Rev 1acfd2f56d72 * ProtocolVersion dependencies removed (raw TLS protocol version numbers are now used) * Code style improvements (tabs, trailing whitespaces, max lines length, etc.) Thanks, Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From simone.bordet at gmail.com Tue Jul 10 17:19:10 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 10 Jul 2018 19:19:10 +0200 Subject: JDK 11+21 SSLSocket.close() deadlock? Message-ID: Hi, Please look at the stack traces below. The server code accept() a SSLSocket, then calls startHandshake() in a different thread. The client code sends the TLS handshake bytes very slowly. The server code waits for a bit for the handshake to finish, then attempts to close the socket, but it cannot due to the deadlock below. The client stops sending the TLS handshake bytes and now the server is stuck forever. I think invoking close() should wake up the read() with an exception, rather than trying to grab the same lock held by the read, as asynchronous closes from other threads happen all the times. The issue does not happen with JDK 9, 10, 11-ea+18, but does happen with 11-ea+21. Thanks! --- "main at 1" prio=5 tid=0x1 nid=NA waiting for monitor entry java.lang.Thread.State: BLOCKED waiting for pool-1-thread-1 at 2224 to release lock on <0xac7> (a sun.security.ssl.SSLSocketImpl) at sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:447) "pool-1-thread-1 at 2224" prio=5 tid=0x19 nid=NA runnable java.lang.Thread.State: RUNNABLE blocks main at 1 at java.net.SocketInputStream.socketRead0(SocketInputStream.java:-1) at java.net.SocketInputStream.socketRead(SocketInputStream.java:115) at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:140) at sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464) at sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167) at sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810) - locked <0xac7> (a sun.security.ssl.SSLSocketImpl) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383) -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Tue Jul 10 17:53:51 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Jul 2018 10:53:51 -0700 Subject: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later) In-Reply-To: References: Message-ID: Hi Norman, It's an interesting user case of the TrustManagerFactory. Please file a bug. Thanks, Xuelei On 7/10/2018 9:57 AM, Alan Bateman wrote: > Forwarding to security-dev. > > On 10/07/2018 17:47, Norman Maurer wrote: >> Hi all, >> >> I just tried to run netty[1] testsuite with the latest jdk11 EA >> release (21) and saw some class-cast-exception with our custom >> SSLEngine implementation >> >> >> Caused by: java.lang.ClassCastException: class >> io.netty.handler.ssl.OpenSslEngine cannot be cast to class >> sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine is >> in unnamed module of loader 'app'; sun.security.ssl.SSLEngineImpl is >> in module java.base of loader 'bootstrap') >> at >> java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgorithmConstraints.java:93) >> at >> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:270) >> at >> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141) >> at >> io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:237) >> at >> io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:621) >> ... 27 more >> >> >> This change seems to be related to: >> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea >> >> I think you miss an instanceof check here in SSLAlgorithmConstraints >> before try to cast to SSLEngineImpl, as otherwise it will be >> impossible to use custom implementations of SSLEngine (which we have >> in netty) with the default TrustManagerFactory. >> >> Does this sound correct ? Should I open a bug-report ? >> >> Bye >> Norman >> >> >> > From anthony.scarpino at oracle.com Tue Jul 10 18:16:03 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 10 Jul 2018 11:16:03 -0700 Subject: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)" In-Reply-To: <44bd0db3-7854-ef83-f18b-44d02702cb9b@oracle.com> References: <7c450b01-0d73-7172-c2bf-995aedfbde1b@oracle.com> <00057e2a-af60-7e1a-dcd0-aad329c44c94@oracle.com> <44bd0db3-7854-ef83-f18b-44d02702cb9b@oracle.com> Message-ID: <6dcf607a-05d4-06f5-93d6-d7c01a1fcd39@oracle.com> Ok, I'm fine with what you have here. thanks Tony On 07/09/2018 05:42 PM, Valerie Peng wrote: > Hi Tony, > > The purpose of the if-block is to ensure that > ArrayIndexOutOfBoundsException is thrown instead of > IndexOutOfBoundsException.? Objects.checkFromIndexSize(...) API is > specified to throw IndexOutOfBoundsException which is more general and > can be thrown when an index of some sort (such as to an array, to a > string, or to a vector) is out of range. ArrayIndexOutOfBoundsException > is a subclass of IndexOutOfBoundsException and is for array index out of > bounds. > > Thanks, > Valerie > > On 7/9/2018 3:14 PM, Anthony Scarpino wrote: >> On 07/03/2018 02:03 PM, Valerie Peng wrote: >>> Hi Tony, >>> >>> Would you have time to review this? Instead of doing the bounds check >>> per block, the changes move the bounds check up one level. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179098 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8179098/webrev.00/ >>> >>> Thanks, >>> Valerie >> >> >> ArrayUtil.java: Line 48 >> - It seems like your not throwing any ArrayIndexOutOfBoundsExceptions, >> is that intentional? The method in the try-catch seems to only throw >> IndexOutOfBoundsException, whole if() seems confusing to me. >> thanks >> >> Tony > From norman.maurer at googlemail.com Tue Jul 10 18:26:07 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Tue, 10 Jul 2018 19:26:07 +0100 Subject: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later) In-Reply-To: References: Message-ID: Will do tomorrow latest. Thanks for the quick reply. Bye Norman > Am 10.07.2018 um 18:53 schrieb Xuelei Fan : > > Hi Norman, > > It's an interesting user case of the TrustManagerFactory. Please file a bug. > > Thanks, > Xuelei > >> On 7/10/2018 9:57 AM, Alan Bateman wrote: >> Forwarding to security-dev. >>> On 10/07/2018 17:47, Norman Maurer wrote: >>> Hi all, >>> >>> I just tried to run netty[1] testsuite with the latest jdk11 EA release (21) and saw some class-cast-exception with our custom SSLEngine implementation >>> >>> >>> Caused by: java.lang.ClassCastException: class io.netty.handler.ssl.OpenSslEngine cannot be cast to class sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine is in unnamed module of loader 'app'; sun.security.ssl.SSLEngineImpl is in module java.base of loader 'bootstrap') >>> at java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgorithmConstraints.java:93) >>> at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:270) >>> at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141) >>> at io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:237) >>> at io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:621) >>> ... 27 more >>> >>> >>> This change seems to be related to: >>> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea >>> >>> I think you miss an instanceof check here in SSLAlgorithmConstraints before try to cast to SSLEngineImpl, as otherwise it will be impossible to use custom implementations of SSLEngine (which we have in netty) with the default TrustManagerFactory. >>> >>> Does this sound correct ? Should I open a bug-report ? >>> >>> Bye >>> Norman >>> >>> >>> From xuelei.fan at oracle.com Tue Jul 10 18:30:38 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 10 Jul 2018 11:30:38 -0700 Subject: JDK 11+21 SSLSocket.close() deadlock? In-Reply-To: References: Message-ID: <94cfbfd3-1c49-db2e-1a2d-654b4a7e157b@oracle.com> Hi Simone, Thank you for reporting this issue. Now it is tracked in JBS: https://bugs.openjdk.java.net/browse/JDK-8207004 In the following stacks, only one lock (on 0xac) can be observed. Can I understand that the read() is blocked, and then the close() is blocked as well? Did you have a test that we can use to reproduce this issue? Thanks, Xuelei On 7/10/2018 10:19 AM, Simone Bordet wrote: > Hi, > > Please look at the stack traces below. > > The server code accept() a SSLSocket, then calls startHandshake() in a > different thread. > The client code sends the TLS handshake bytes very slowly. > The server code waits for a bit for the handshake to finish, then > attempts to close the socket, but it cannot due to the deadlock below. > The client stops sending the TLS handshake bytes and now the server is > stuck forever. > > I think invoking close() should wake up the read() with an exception, > rather than trying to grab the same lock held by the read, as > asynchronous closes from other threads happen all the times. > > The issue does not happen with JDK 9, 10, 11-ea+18, but does happen > with 11-ea+21. > > Thanks! > > --- > > "main at 1" prio=5 tid=0x1 nid=NA waiting for monitor entry > java.lang.Thread.State: BLOCKED > waiting for pool-1-thread-1 at 2224 to release lock on <0xac7> (a > sun.security.ssl.SSLSocketImpl) > at sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:447) > > "pool-1-thread-1 at 2224" prio=5 tid=0x19 nid=NA runnable > java.lang.Thread.State: RUNNABLE > blocks main at 1 > at java.net.SocketInputStream.socketRead0(SocketInputStream.java:-1) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:115) > at java.net.SocketInputStream.read(SocketInputStream.java:168) > at java.net.SocketInputStream.read(SocketInputStream.java:140) > at sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464) > at sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167) > at sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) > at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:877) > at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:810) > - locked <0xac7> (a sun.security.ssl.SSLSocketImpl) > at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383) > From andrew.w.wong at oracle.com Tue Jul 10 19:11:00 2018 From: andrew.w.wong at oracle.com (Andrew Wong) Date: Tue, 10 Jul 2018 12:11:00 -0700 (PDT) Subject: =?UTF-8?B?KE9wZW4pIFJGUjogODIwNTk2NzogUmVtb3ZlwqBzdW4vc2VjdXJpdHkva3I=?= =?UTF-8?B?YjUvYXV0by9VbmJvdW5kU1NMLmphdmEgZnJvbSBQcm9ibGVtTGlzdC50eHQ=?= Message-ID: <5465399e-d59d-4b40-b55a-5cd2a4595650@default> Dear Security Developer, Please review the following fix for bug id 8205967. The test associated with UnboundSSL.java was removed in a previous fix but is still listed in ProblemList.txt. ProblemList.txt has been updated accordingly by removing the test. http://cr.openjdk.java.net/~rhalade/andrew/8205967/webrev.00/ Thank you, Andrew Wong From valerie.peng at oracle.com Tue Jul 10 21:12:45 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 10 Jul 2018 14:12:45 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized Message-ID: Hi Brad, Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? No source code changes, but just updating javadoc to mention the possible failure case. Otherwise, JCK team expects a parameter object or null being returned. I filed a CSR to track the javadoc clarification. Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 Thanks, Valerie From Xuelei.Fan at Oracle.Com Tue Jul 10 21:44:33 2018 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 10 Jul 2018 14:44:33 -0700 Subject: =?utf-8?Q?Re:_=28Open=29_RFR:_8205967:_Remove=C2=A0sun/security/krb5?= =?utf-8?Q?/auto/UnboundSSL.java_from_ProblemList.txt?= In-Reply-To: <5465399e-d59d-4b40-b55a-5cd2a4595650@default> References: <5465399e-d59d-4b40-b55a-5cd2a4595650@default> Message-ID: <1F549EC2-FB77-4DD6-9DA3-E53AC1F9D7D6@Oracle.Com> Looks fine to me. Thanks, Xuelei > On Jul 10, 2018, at 12:11 PM, Andrew Wong wrote: > > Dear Security Developer, > > Please review the following fix for bug id 8205967. The test associated with UnboundSSL.java was removed in a previous fix but is still listed in ProblemList.txt. ProblemList.txt has been updated accordingly by removing the test. > > http://cr.openjdk.java.net/~rhalade/andrew/8205967/webrev.00/ > > Thank you, > > Andrew Wong From valerie.peng at oracle.com Wed Jul 11 01:41:06 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 10 Jul 2018 18:41:06 -0700 Subject: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)" In-Reply-To: <6dcf607a-05d4-06f5-93d6-d7c01a1fcd39@oracle.com> References: <7c450b01-0d73-7172-c2bf-995aedfbde1b@oracle.com> <00057e2a-af60-7e1a-dcd0-aad329c44c94@oracle.com> <44bd0db3-7854-ef83-f18b-44d02702cb9b@oracle.com> <6dcf607a-05d4-06f5-93d6-d7c01a1fcd39@oracle.com> Message-ID: <1aaa75a8-7299-0ea2-cab7-77e888a3714f@oracle.com> Thanks for the review~ Valerie On 7/10/2018 11:16 AM, Anthony Scarpino wrote: > Ok, I'm fine with what you have here. > > thanks > > Tony > > > On 07/09/2018 05:42 PM, Valerie Peng wrote: >> Hi Tony, >> >> The purpose of the if-block is to ensure that >> ArrayIndexOutOfBoundsException is thrown instead of >> IndexOutOfBoundsException.? Objects.checkFromIndexSize(...) API is >> specified to throw IndexOutOfBoundsException which is more general >> and can be thrown when an index of some sort (such as to an array, to >> a string, or to a vector) is out of range. >> ArrayIndexOutOfBoundsException is a subclass of >> IndexOutOfBoundsException and is for array index out of bounds. >> >> Thanks, >> Valerie >> >> On 7/9/2018 3:14 PM, Anthony Scarpino wrote: >>> On 07/03/2018 02:03 PM, Valerie Peng wrote: >>>> Hi Tony, >>>> >>>> Would you have time to review this? Instead of doing the bounds >>>> check per block, the changes move the bounds check up one level. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179098 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8179098/webrev.00/ >>>> >>>> Thanks, >>>> Valerie >>> >>> >>> ArrayUtil.java: Line 48 >>> - It seems like your not throwing any >>> ArrayIndexOutOfBoundsExceptions, is that intentional? The method in >>> the try-catch seems to only throw IndexOutOfBoundsException, whole >>> if() seems confusing to me. >>> thanks >>> >>> Tony >> > From weijun.wang at oracle.com Wed Jul 11 02:16:47 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Jul 2018 10:16:47 +0800 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: Message-ID: Hi Valerie About "it *may* return", do you mean it could also return null? My understanding is no. Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. Thanks Max > On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: > > Hi Brad, > > Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? > No source code changes, but just updating javadoc to mention the possible failure case. > Otherwise, JCK team expects a parameter object or null being returned. > I filed a CSR to track the javadoc clarification. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 > Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 > > Thanks, > Valerie > > > From sha.jiang at oracle.com Wed Jul 11 02:52:03 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 11 Jul 2018 10:52:03 +0800 Subject: RFR[11] JDK-8199645: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with Connection reset In-Reply-To: <48e99066-11ff-3a71-29e3-d7e7466d859e@oracle.com> References: <8b349aec-e1d9-dd03-8755-c5cf19aa2c6c@oracle.com> <48e99066-11ff-3a71-29e3-d7e7466d859e@oracle.com> Message-ID: Hi Xuelei, Thanks for your review! The fix just was pushed. I adjusted the following longer lines: ?129???????????????? System.out.println("Client got UNEXPECTED SSLHandshakeException:"); ?134???????????????? System.out.println("Client got expected SSLHandshakeException:"); In addition, the parentheses, which encloses the new statement, also was removed. ?269???????? (new TestEnabledProtocols( ?270???????????????? serverProtocols, ?271???????????????? clientProtocols, ?272???????????????? exceptionExpected, ?273???????????????? selectedProtocol)).run(); Best regards, John Jiang On 2018/7/10 21:33, Xuelei Fan wrote: > Looks fine to me.? Please limit each line in 80 characters. > > Thanks, > Xuelei > > On 7/10/2018 2:27 AM, sha.jiang at oracle.com wrote: >> Hi, >> javax/net/ssl/SSLSession/TestEnabledProtocols.java may have some >> problem on sync between server and client. >> And it would be better to refactor this test with >> SSLSocketTemplate.java. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8199645/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8199645 >> >> Best regards, >> John Jiang >> > From norman.maurer at googlemail.com Wed Jul 11 06:21:44 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 11 Jul 2018 08:21:44 +0200 Subject: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later) In-Reply-To: References: Message-ID: Submitted it via https://bugreport.java.com . Please let me know once it ?transferred? to https://bugs.openjdk.java.net Bye Norman > On 10. Jul 2018, at 20:26, Norman Maurer wrote: > > Will do tomorrow latest. > > Thanks for the quick reply. > > Bye > Norman > >> Am 10.07.2018 um 18:53 schrieb Xuelei Fan : >> >> Hi Norman, >> >> It's an interesting user case of the TrustManagerFactory. Please file a bug. >> >> Thanks, >> Xuelei >> >>> On 7/10/2018 9:57 AM, Alan Bateman wrote: >>> Forwarding to security-dev. >>>> On 10/07/2018 17:47, Norman Maurer wrote: >>>> Hi all, >>>> >>>> I just tried to run netty[1] testsuite with the latest jdk11 EA release (21) and saw some class-cast-exception with our custom SSLEngine implementation >>>> >>>> >>>> Caused by: java.lang.ClassCastException: class io.netty.handler.ssl.OpenSslEngine cannot be cast to class sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine is in unnamed module of loader 'app'; sun.security.ssl.SSLEngineImpl is in module java.base of loader 'bootstrap') >>>> at java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgorithmConstraints.java:93) >>>> at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:270) >>>> at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141) >>>> at io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:237) >>>> at io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:621) >>>> ... 27 more >>>> >>>> >>>> This change seems to be related to: >>>> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea >>>> >>>> I think you miss an instanceof check here in SSLAlgorithmConstraints before try to cast to SSLEngineImpl, as otherwise it will be impossible to use custom implementations of SSLEngine (which we have in netty) with the default TrustManagerFactory. >>>> >>>> Does this sound correct ? Should I open a bug-report ? >>>> >>>> Bye >>>> Norman >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pallavi.sonal at oracle.com Wed Jul 11 06:54:34 2018 From: pallavi.sonal at oracle.com (Pallavi Sonal) Date: Tue, 10 Jul 2018 23:54:34 -0700 (PDT) Subject: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later) Message-ID: <52674290-6733-49ee-8475-553cadf36326@default> Hi Norman , Please refer https://bugs.openjdk.java.net/browse/JDK-8207029 to view your report, it has been moved to JDK. Thanks, Pallavi Sonal Message: 5 Date: Wed, 11 Jul 2018 08:21:44 +0200 From: Norman Maurer To: Xuelei Fan Cc: OpenJDK Dev list Subject: Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later) Message-ID: Content-Type: text/plain; charset="utf-8" Submitted it via https://bugreport.java.com . Please let me know once it ?transferred? to https://bugs.openjdk.java.net Bye Norman > On 10. Jul 2018, at 20:26, Norman Maurer wrote: > > Will do tomorrow latest. > > Thanks for the quick reply. > > Bye > Norman > >> Am 10.07.2018 um 18:53 schrieb Xuelei Fan : >> >> Hi Norman, >> >> It's an interesting user case of the TrustManagerFactory. Please file a bug. >> >> Thanks, >> Xuelei >> >>> On 7/10/2018 9:57 AM, Alan Bateman wrote: >>> Forwarding to security-dev. >>>> On 10/07/2018 17:47, Norman Maurer wrote: >>>> Hi all, >>>> >>>> I just tried to run netty[1] testsuite with the latest jdk11 EA >>>> release (21) and saw some class-cast-exception with our custom >>>> SSLEngine implementation >>>> >>>> >>>> Caused by: java.lang.ClassCastException: class >>>> io.netty.handler.ssl.OpenSslEngine cannot be cast to class >>>> sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine >>>> is in unnamed module of loader 'app'; >>>> sun.security.ssl.SSLEngineImpl is in module java.base of loader >>>> 'bootstrap') at >>>> java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgori >>>> thmConstraints.java:93) at >>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509Tr >>>> ustManagerImpl.java:270) at >>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted( >>>> X509TrustManagerImpl.java:141) at >>>> io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedT >>>> rustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientConte >>>> xt.java:237) at >>>> io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertifi >>>> cateVerifier.verify(ReferenceCountedOpenSslContext.java:621) >>>> ... 27 more >>>> >>>> >>>> This change seems to be related to: >>>> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea >>>> >>>> I think you miss an instanceof check here in SSLAlgorithmConstraints before try to cast to SSLEngineImpl, as otherwise it will be impossible to use custom implementations of SSLEngine (which we have in netty) with the default TrustManagerFactory. >>>> >>>> Does this sound correct ? Should I open a bug-report ? >>>> >>>> Bye >>>> Norman >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: End of security-dev Digest, Vol 133, Issue 12 ********************************************* From simone.bordet at gmail.com Wed Jul 11 09:59:08 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 11 Jul 2018 11:59:08 +0200 Subject: JDK 11+21 SSLSocket.close() deadlock? In-Reply-To: <94cfbfd3-1c49-db2e-1a2d-654b4a7e157b@oracle.com> References: <94cfbfd3-1c49-db2e-1a2d-654b4a7e157b@oracle.com> Message-ID: Hi, On Wed, Jul 11, 2018 at 2:25 AM Xuelei Fan wrote: > > Hi Simone, > > Thank you for reporting this issue. Now it is tracked in JBS: > https://bugs.openjdk.java.net/browse/JDK-8207004 > > In the following stacks, only one lock (on 0xac) can be observed. Can I > understand that the read() is blocked, and then the close() is blocked > as well? Did you have a test that we can use to reproduce this issue? Yes, it's pretty crude but reduces at minimum the dependencies. You have to provide a valid sslContext variable, but that should be done for your environment. Looking at sun.security.ssl.SSLSocketImpl.close(), I see that it tries to grab the lock for read and then for write. While the test case below shows a problem for reads, I believe the same problem can be shown when the SSLSocket is blocked in writes due to TCP congestion, and some other thread tries to asynchronously close() it. Thanks! public void testDeadlock() throws Exception { int port = 8899; // TODO: provide a valid sslContext here. SSLServerSocket acceptor = (SSLServerSocket)sslContext.getServerSocketFactory().createServerSocket(port); Socket client = new Socket("localhost", port); SSLSocket sslServer = (SSLSocket)acceptor.accept(); CompletableFuture.runAsync(() -> { try { sslServer.startHandshake(); } catch (Throwable x) { x.printStackTrace(); } }); // Wait for sslServer to start reading from the client. Thread.sleep(1000); // Hangs here. sslServer.close(); client.close(); } -- 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 norman.maurer at googlemail.com Wed Jul 11 13:11:40 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 11 Jul 2018 15:11:40 +0200 Subject: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later) In-Reply-To: <52674290-6733-49ee-8475-553cadf36326@default> References: <52674290-6733-49ee-8475-553cadf36326@default> Message-ID: <7386B290-2B8E-4FEF-B8B3-84E5C1670AD2@googlemail.com> Hey Pallavi, Thanks :) I just noticed you will also need to do the instanceof before you cast to SocketImpl in this class. Unfortunately I can not add a comment this issue directly (it seems), so hopefully mention it here is good enough. Bye Norman > On 11. Jul 2018, at 08:54, Pallavi Sonal wrote: > > Hi Norman , > Please refer https://bugs.openjdk.java.net/browse/JDK-8207029 to view your report, it has been moved to JDK. > > Thanks, > Pallavi Sonal > > Message: 5 > Date: Wed, 11 Jul 2018 08:21:44 +0200 > From: Norman Maurer > To: Xuelei Fan > Cc: OpenJDK Dev list > Subject: Re: Unable to use custom SSLEngine with default > TrustManagerFactory after updating to ea20 (and later) > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Submitted it via https://bugreport.java.com . > > Please let me know once it ?transferred? to https://bugs.openjdk.java.net > > > Bye > Norman > > > >> On 10. Jul 2018, at 20:26, Norman Maurer wrote: >> >> Will do tomorrow latest. >> >> Thanks for the quick reply. >> >> Bye >> Norman >> >>> Am 10.07.2018 um 18:53 schrieb Xuelei Fan : >>> >>> Hi Norman, >>> >>> It's an interesting user case of the TrustManagerFactory. Please file a bug. >>> >>> Thanks, >>> Xuelei >>> >>>> On 7/10/2018 9:57 AM, Alan Bateman wrote: >>>> Forwarding to security-dev. >>>>> On 10/07/2018 17:47, Norman Maurer wrote: >>>>> Hi all, >>>>> >>>>> I just tried to run netty[1] testsuite with the latest jdk11 EA >>>>> release (21) and saw some class-cast-exception with our custom >>>>> SSLEngine implementation >>>>> >>>>> >>>>> Caused by: java.lang.ClassCastException: class >>>>> io.netty.handler.ssl.OpenSslEngine cannot be cast to class >>>>> sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine >>>>> is in unnamed module of loader 'app'; >>>>> sun.security.ssl.SSLEngineImpl is in module java.base of loader >>>>> 'bootstrap') at >>>>> java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgori >>>>> thmConstraints.java:93) at >>>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509Tr >>>>> ustManagerImpl.java:270) at >>>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted( >>>>> X509TrustManagerImpl.java:141) at >>>>> io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedT >>>>> rustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientConte >>>>> xt.java:237) at >>>>> io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertifi >>>>> cateVerifier.verify(ReferenceCountedOpenSslContext.java:621) >>>>> ... 27 more >>>>> >>>>> >>>>> This change seems to be related to: >>>>> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea >>>>> >>>>> I think you miss an instanceof check here in SSLAlgorithmConstraints before try to cast to SSLEngineImpl, as otherwise it will be impossible to use custom implementations of SSLEngine (which we have in netty) with the default TrustManagerFactory. >>>>> >>>>> Does this sound correct ? Should I open a bug-report ? >>>>> >>>>> Bye >>>>> Norman >>>>> >>>>> >>>>> > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > End of security-dev Digest, Vol 133, Issue 12 > ********************************************* From sean.mullan at oracle.com Wed Jul 11 13:56:41 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 11 Jul 2018 09:56:41 -0400 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: Message-ID: Yes, I think if an implementation can throw an exception in this case, we should add that as an @throws. For example, something like the following: @throws ProviderException if this signature engine requires parameters but does not support default or randomly generated parameter values --Sean On 7/10/18 10:16 PM, Weijun Wang wrote: > Hi Valerie > > About "it *may* return", do you mean it could also return null? My understanding is no. > > Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? > > Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. > > Thanks > Max > > >> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >> >> Hi Brad, >> >> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >> No source code changes, but just updating javadoc to mention the possible failure case. >> Otherwise, JCK team expects a parameter object or null being returned. >> I filed a CSR to track the javadoc clarification. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >> >> Thanks, >> Valerie >> >> >> > From sean.mullan at oracle.com Wed Jul 11 14:41:25 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 11 Jul 2018 10:41:25 -0400 Subject: RFR 8206915: XDH TCK issues In-Reply-To: <8e88159f-85c2-244c-a511-c56a1af48197@oracle.com> References: <8e88159f-85c2-244c-a511-c56a1af48197@oracle.com> Message-ID: <28d0183a-3d49-1126-0666-37a0da9ca930@oracle.com> XDHKeyAgreement.java 176 byte[] result = secret; Shouldn't this be: 176 byte[] result = secret.clone(); since engineGenerateSecret() says it is returned in a new buffer. Looks fine otherwise. --Sean On 7/9/18 11:29 AM, Adam Petcher wrote: > A couple of conformance issues were found during TCK development for > XDH. Both required very small modifications to fix, so I put them under > the same ticket/review in order to save time. The actual information > about the issues can be found in the sub-tasks of the ticket. > > This fix needs to go into JDK 11, so I'm hoping a Reviewer can take a > look at this soon. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8206915 > Webrev: http://cr.openjdk.java.net/~apetcher/8206915/webrev.00/ > From matthias.baesken at sap.com Wed Jul 11 14:43:05 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 11 Jul 2018 14:43:05 +0000 Subject: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk Message-ID: <1ce14de946914cf89ec60b5837e1129f@sap.com> Hello, currently the security related test security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk. I currently get an exception : java.lang.RuntimeException: TEST FAILED: unexpected status of EE certificate at ValidatePathWithParams.validate(ValidatePathWithParams.java:193) at RootCA1.runTest(QuoVadisCA.java:186) at QuoVadisCA.main(QuoVadisCA.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:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:834) JavaTest Message: Test threw exception: java.lang.RuntimeException: TEST FAILED: unexpected status of EE certificate JavaTest Message: shutting down test ... and in stdout there is a better message that seems to show the reason , a certificate is expected to be "GOOD" but it has been revoked Fri Jan 19 15:39:57 CET 2018 . Should the test be updated with more recent certs (seems they are hardwired in the test java source) ? ===================================================== CONFIGURATION ===================================================== http.proxyHost :proxy http.proxyPort :8080 https.proxyHost :proxy https.proxyPort :8080 https.socksProxyHost :null https.socksProxyPort :null jdk.certpath.disabledAlgorithms :MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 Revocation options :[PREFER_CRLS, NO_FALLBACK] OCSP responder set :null Trusted root set: false Expected EE Status:GOOD ===================================================== Received exception: java.security.cert.CertPathValidatorException: Certificate has been revoked, reason: SUPERSEDED, revocation date: Fri Jan 19 15:39:57 CET 2018, authority: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM, extension OIDs: [2.5.29.21] Expected Certificate status: GOOD Certificate status after validation: REVOKED Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Wed Jul 11 15:01:00 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 11 Jul 2018 11:01:00 -0400 Subject: RFR 8206915: XDH TCK issues In-Reply-To: <28d0183a-3d49-1126-0666-37a0da9ca930@oracle.com> References: <8e88159f-85c2-244c-a511-c56a1af48197@oracle.com> <28d0183a-3d49-1126-0666-37a0da9ca930@oracle.com> Message-ID: On 7/11/2018 10:41 AM, Sean Mullan wrote: > XDHKeyAgreement.java > > 176???????? byte[] result = secret; > > Shouldn't this be: > > 176???????? byte[] result = secret.clone(); > > since engineGenerateSecret() says it is returned in a new buffer. I don't think cloning is necessary. The new array is created in engineDoPhase, and it is always set to null in engineGenerateSecret after it is returned or copied to the output buffer. In essence, this overload of engineDoPhase transfers ownership of the array, and the other one destroys it. So this engineDoPhase effectively returns a new array, and I don't think it is possible for two clients (in the same thread) to get the same array from these methods. Though I would appreciate it if you could double-check this and make sure you agree. From rajan.halade at oracle.com Wed Jul 11 15:42:02 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 11 Jul 2018 08:42:02 -0700 Subject: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk In-Reply-To: <1ce14de946914cf89ec60b5837e1129f@sap.com> References: <1ce14de946914cf89ec60b5837e1129f@sap.com> Message-ID: <41263153-e2e1-f9e6-ab2d-010688b74d57@oracle.com> Thanks for the report, I have filed JDK-8207059. Yes, the test certificate used here need to be updated. - Rajan On 7/11/18 7:43 AM, Baesken, Matthias wrote: > > ? and in stdout? there is ?a better message that seems to show the > reason ,?? a certificate is expected to? be ?GOOD??? but it? has been > revoked ?Fri Jan 19 15:39:57 CET 2018?? . > > Should? the? test?? be updated? with? more?? recent? certs?? (seems > they are hardwired in the test java source) ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Jul 11 15:42:16 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jul 2018 08:42:16 -0700 Subject: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later) In-Reply-To: References: Message-ID: It is now tracked in JBS: https://bugs.openjdk.java.net/browse/JDK-8207029 Thanks, Xuelei On 7/10/2018 11:21 PM, Norman Maurer wrote: > Submitted it via https://bugreport.java.com. > > Please let me know once it ?transferred? to https://bugs.openjdk.java.net > > > Bye > Norman > > > >> On 10. Jul 2018, at 20:26, Norman Maurer > > wrote: >> >> Will do tomorrow latest. >> >> Thanks for the quick reply. >> >> Bye >> Norman >> >>> Am 10.07.2018 um 18:53 schrieb Xuelei Fan >> >: >>> >>> Hi Norman, >>> >>> It's an interesting user case of the TrustManagerFactory. ?Please >>> file a bug. >>> >>> Thanks, >>> Xuelei >>> >>>> On 7/10/2018 9:57 AM, Alan Bateman wrote: >>>> Forwarding to security-dev. >>>>> On 10/07/2018 17:47, Norman Maurer wrote: >>>>> Hi all, >>>>> >>>>> I just tried to run netty[1] testsuite with the latest jdk11 EA >>>>> release (21) and saw some class-cast-exception with our custom >>>>> SSLEngine implementation >>>>> >>>>> >>>>> Caused by: java.lang.ClassCastException: class >>>>> io.netty.handler.ssl.OpenSslEngine cannot be cast to class >>>>> sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine >>>>> is in unnamed module of loader 'app'; >>>>> sun.security.ssl.SSLEngineImpl is in module java.base of loader >>>>> 'bootstrap') >>>>> at >>>>> java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgorithmConstraints.java:93) >>>>> at >>>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:270) >>>>> at >>>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141) >>>>> at >>>>> io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:237) >>>>> at >>>>> io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:621) >>>>> ... 27 more >>>>> >>>>> >>>>> This change seems to be related to: >>>>> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea >>>>> >>>>> I think you miss an instanceof check here in >>>>> SSLAlgorithmConstraints before try to cast to SSLEngineImpl, as >>>>> otherwise it will be impossible to use custom implementations of >>>>> SSLEngine (which we have in netty) with the default >>>>> TrustManagerFactory. >>>>> >>>>> Does this sound correct ? Should I open a bug-report ? >>>>> >>>>> Bye >>>>> Norman >>>>> >>>>> >>>>> > From matthias.baesken at sap.com Wed Jul 11 15:58:48 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 11 Jul 2018 15:58:48 +0000 Subject: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk In-Reply-To: <41263153-e2e1-f9e6-ab2d-010688b74d57@oracle.com> References: <1ce14de946914cf89ec60b5837e1129f@sap.com> <41263153-e2e1-f9e6-ab2d-010688b74d57@oracle.com> Message-ID: <57b1a24d0a64432db3b0a34913ed9516@sap.com> Hi Rajan, thanks for filing JDK-8207059. Best regards, Matthias From: Rajan Halade [mailto:rajan.halade at oracle.com] Sent: Mittwoch, 11. Juli 2018 17:42 To: Baesken, Matthias ; security-dev at openjdk.java.net Subject: Re: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk Thanks for the report, I have filed JDK-8207059. Yes, the test certificate used here need to be updated. - Rajan On 7/11/18 7:43 AM, Baesken, Matthias wrote: ... and in stdout there is a better message that seems to show the reason , a certificate is expected to be "GOOD" but it has been revoked Fri Jan 19 15:39:57 CET 2018 . Should the test be updated with more recent certs (seems they are hardwired in the test java source) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Jul 11 16:02:55 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jul 2018 09:02:55 -0700 Subject: RFR 8206915: XDH TCK issues In-Reply-To: References: <8e88159f-85c2-244c-a511-c56a1af48197@oracle.com> <28d0183a-3d49-1126-0666-37a0da9ca930@oracle.com> Message-ID: <12c01858-c554-6259-e92e-03bc0a3518fa@oracle.com> Does it make sense if secret is not temporarily stored as a class filed? Xuelei On 7/11/2018 8:01 AM, Adam Petcher wrote: > On 7/11/2018 10:41 AM, Sean Mullan wrote: > >> XDHKeyAgreement.java >> >> 176???????? byte[] result = secret; >> >> Shouldn't this be: >> >> 176???????? byte[] result = secret.clone(); >> >> since engineGenerateSecret() says it is returned in a new buffer. > > I don't think cloning is necessary. The new array is created in > engineDoPhase, and it is always set to null in engineGenerateSecret > after it is returned or copied to the output buffer. In essence, this > overload of engineDoPhase transfers ownership of the array, and the > other one destroys it. So this engineDoPhase effectively returns a new > array, and I don't think it is possible for two clients (in the same > thread) to get the same array from these methods. Though I would > appreciate it if you could double-check this and make sure you agree. From xuelei.fan at oracle.com Wed Jul 11 16:11:55 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jul 2018 09:11:55 -0700 Subject: [11] RFR 8206189: sun/security/pkcs12/EmptyPassword.java fails with Sequence tag error In-Reply-To: <264576B5-1358-477F-8970-0ABC145B8225@oracle.com> References: <264576B5-1358-477F-8970-0ABC145B8225@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 7/9/2018 8:39 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8206189/webrev.00/ > > When the password is empty, some pkcs12 implementations actually use "new char[1]" internally. Therefore PKCS12KeyStore tries both "new char[0]" and "new char[1]". Occasionally, an encrypted block can be decrypted by both. If the real password is "new char[1]" but we decrypt successfully with "new char[0]", the output will be garbage and will not be parsed correctly. > > This fix puts the parsing code inside the retry block to "validate" the decrypted data. If it cannot be parsed correctly, the 2nd password will be retried. > > No new regression test, the failed test will be used to verify the fix. > > Thanks > Max > From adam.petcher at oracle.com Wed Jul 11 16:12:12 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 11 Jul 2018 12:12:12 -0400 Subject: RFR 8206915: XDH TCK issues In-Reply-To: <12c01858-c554-6259-e92e-03bc0a3518fa@oracle.com> References: <8e88159f-85c2-244c-a511-c56a1af48197@oracle.com> <28d0183a-3d49-1126-0666-37a0da9ca930@oracle.com> <12c01858-c554-6259-e92e-03bc0a3518fa@oracle.com> Message-ID: <1366d78a-0eb9-0ce0-a8bb-f2c80ec121ca@oracle.com> On 7/11/2018 12:02 PM, Xuelei Fan wrote: > Does it make sense if secret is not temporarily stored as a class filed? I agree that it's a bit strange, but it is organized this way because of the zero result check described in the RFC. If the result of the key agreement is zero, then that means that the public key is invalid. So we compute the shared secret early in engineDoPhase so we can throw an InvalidKeyException at the correct time. Then the computed secret is kept around so it can be returned by engineGenerateSecret. > > Xuelei From claes.redestad at oracle.com Wed Jul 11 18:41:35 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 11 Jul 2018 20:41:35 +0200 Subject: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)" In-Reply-To: <44bd0db3-7854-ef83-f18b-44d02702cb9b@oracle.com> References: <7c450b01-0d73-7172-c2bf-995aedfbde1b@oracle.com> <00057e2a-af60-7e1a-dcd0-aad329c44c94@oracle.com> <44bd0db3-7854-ef83-f18b-44d02702cb9b@oracle.com> Message-ID: FWIW, but as we're in java.base there's a way to use the jdk.internal.util.Preconditions API backing Objects.checkFrom* methods directly, which lets you control the type of exception thrown: private static final BiFunction, ArrayIndexOutOfBoundsException> AIOOBE_SUPPLIER = Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new); public static void nullAndBoundsCheck(byte[] array, int offset, int len) { Preconditions.checkFromIndexSize(offset, len, array.length, AIOOBE_SUPPLIER); // implicit null check of array } Prior art is really only the java.lang.invoke.VarHandle.AIOOBE_SUPPLIER (which is used from generated code, e.g. j.l.i.VarHandleInts); maybe it could be refactored to some internal package for reuse. (I'd remove the explicit null check and lower-case the N in NullAndBoundsCheck, regardless) Thanks! /Claes On 2018-07-10 02:42, Valerie Peng wrote: > Hi Tony, > > The purpose of the if-block is to ensure that > ArrayIndexOutOfBoundsException is thrown instead of > IndexOutOfBoundsException.? Objects.checkFromIndexSize(...) API is > specified to throw IndexOutOfBoundsException which is more general and > can be thrown when an index of some sort (such as to an array, to a > string, or to a vector) is out of range. > ArrayIndexOutOfBoundsException is a subclass of > IndexOutOfBoundsException and is for array index out of bounds. > > Thanks, > Valerie > > On 7/9/2018 3:14 PM, Anthony Scarpino wrote: >> On 07/03/2018 02:03 PM, Valerie Peng wrote: >>> Hi Tony, >>> >>> Would you have time to review this? Instead of doing the bounds >>> check per block, the changes move the bounds check up one level. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179098 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8179098/webrev.00/ >>> >>> Thanks, >>> Valerie >> >> >> ArrayUtil.java: Line 48 >> - It seems like your not throwing any >> ArrayIndexOutOfBoundsExceptions, is that intentional? The method in >> the try-catch seems to only throw IndexOutOfBoundsException, whole >> if() seems confusing to me. >> thanks >> >> Tony > From sean.mullan at oracle.com Wed Jul 11 18:59:48 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 11 Jul 2018 14:59:48 -0400 Subject: RFR 8206915: XDH TCK issues In-Reply-To: References: <8e88159f-85c2-244c-a511-c56a1af48197@oracle.com> <28d0183a-3d49-1126-0666-37a0da9ca930@oracle.com> Message-ID: On 7/11/18 11:01 AM, Adam Petcher wrote: > On 7/11/2018 10:41 AM, Sean Mullan wrote: > >> XDHKeyAgreement.java >> >> 176???????? byte[] result = secret; >> >> Shouldn't this be: >> >> 176???????? byte[] result = secret.clone(); >> >> since engineGenerateSecret() says it is returned in a new buffer. > > I don't think cloning is necessary. The new array is created in > engineDoPhase, and it is always set to null in engineGenerateSecret > after it is returned or copied to the output buffer. In essence, this > overload of engineDoPhase transfers ownership of the array, and the > other one destroys it. So this engineDoPhase effectively returns a new > array, and I don't think it is possible for two clients (in the same > thread) to get the same array from these methods. Though I would > appreciate it if you could double-check this and make sure you agree. Ok, I see. I think it should be ok. I checked and the KeyAgreement/Spi APIs do not specifically say anything about concurrent access by multiple threads. However, typically I think it's normal to assume that they don't support concurrent access (i.e. unexpected behavior may result if so) unless it specifically says so. --Sean From xuelei.fan at oracle.com Wed Jul 11 19:13:52 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jul 2018 12:13:52 -0700 Subject: RFR 8206915: XDH TCK issues In-Reply-To: <1366d78a-0eb9-0ce0-a8bb-f2c80ec121ca@oracle.com> References: <8e88159f-85c2-244c-a511-c56a1af48197@oracle.com> <28d0183a-3d49-1126-0666-37a0da9ca930@oracle.com> <12c01858-c554-6259-e92e-03bc0a3518fa@oracle.com> <1366d78a-0eb9-0ce0-a8bb-f2c80ec121ca@oracle.com> Message-ID: <98ebf7e3-9695-354f-94fb-3a6eb456d4be@oracle.com> On 7/11/2018 9:12 AM, Adam Petcher wrote: > On 7/11/2018 12:02 PM, Xuelei Fan wrote: > >> Does it make sense if secret is not temporarily stored as a class filed? > > I agree that it's a bit strange, but it is organized this way because of > the zero result check described in the RFC. If the result of the key > agreement is zero, then that means that the public key is invalid. So we > compute the shared secret early in engineDoPhase so we can throw an > InvalidKeyException at the correct time. Then the computed secret is > kept around so it can be returned by engineGenerateSecret. > I see. Thanks, Xuelei From simone.bordet at gmail.com Wed Jul 11 22:06:43 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 12 Jul 2018 00:06:43 +0200 Subject: SSLEngine weird behavior in 11+21? Message-ID: Hi, I can see this (weird) behavior in SSLEngine for TLS 1.3 in JDK 11+21. It's a simple new connection (no resumption) that performs a TLS 1.3 handshake. The bytes numbers are those that I get, they may be different for others depending on certificate size, etc. 1. Client wraps 394 bytes then goes into NEED_UNWRAP. 2. Server unwraps 394 bytes then goes into NEED_TASK and then into NEED_WRAP. 3. Server wraps (in 3 wraps) 160, 6 and 907 bytes then goes into NEED_UNWRAP. 4. Client unwraps 160 bytes then goes into NEED_TASK and then into NEED_WRAP (?) 5. Client wraps 6 bytes, then goes into NEED_UNWRAP. 6. Client unwraps (in 2 unwraps) 6 and 907 bytes, then goes into NEED_TASK and then into NEED_WRAP. 7. Client wraps 58 bytes and goes into FINISHED (?) 8. Server unwraps (in 2 unwraps) 6 and 58 bytes then goes into NEED_WRAP. 9. Server wraps 72 bytes then goes into FINISHED. 10. Client MUST unwrap those 72 bytes going again into FINISHED (which already happened at 7). There are 2 things that I find weird: A) That at 4, the client goes into NEED_WRAP, even if it has not finished to unwrap what the server sent. Apparently, it only goes into NEED_WRAP to generate a CHANGE_CIPHER_SPEC (I am guessing from the number of bytes generated), but then goes back into NEED_UNWRAP to finish reading what the server sent. This is also not optimal as it forces applications to do something with those 6 bytes: either put them aside (additional data structures that may not be needed) or - worse - write them to the server causing an additional write (after all the effort TLS 1.3 put in to have a 1 RTT handshake). I think that step 4 should go into NEED_UNWRAP, and that step 5 and step 6 should be switched, so that the client would unwrap the 160, 6 and 907 sent by the server, and only after wrapping the 6 and the 58. To be clear, the current behavior is (u==unwrap, w=wrap): u160, w6, u6, u907, w58. I think it should be: u160, u6, u907, w6, w58. Is there any reason that the 6 bytes needs to be generated in-between the processing of the frames sent by the server? B)That at 7 the client goes into FINISHED, but it is not finished really: in fact it needs to perform step 10, but there is no indication from the SSLEngine that it must do so. Currently, step 7 says the client is finished and there is no clue that it must unwrap those last 72 bytes. I think step 7 should go into NEED_UNWRAP instead, and only at 10 go into FINISHED. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From valerie.peng at oracle.com Wed Jul 11 23:00:22 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 11 Jul 2018 16:00:22 -0700 Subject: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)" In-Reply-To: References: <7c450b01-0d73-7172-c2bf-995aedfbde1b@oracle.com> <00057e2a-af60-7e1a-dcd0-aad329c44c94@oracle.com> <44bd0db3-7854-ef83-f18b-44d02702cb9b@oracle.com> Message-ID: Sure, your suggestion sounds good. I have updated the webrev accordingly at http://cr.openjdk.java.net/~valeriep/8179098/webrev.01/ Will integrate after mach5 run is done. Thanks! Valerie On 7/11/2018 11:41 AM, Claes Redestad wrote: > FWIW, but as we're in java.base there's a way to use the > jdk.internal.util.Preconditions API backing Objects.checkFrom* methods > directly, which lets you control the type of exception thrown: > > private static final BiFunction, > ArrayIndexOutOfBoundsException> AIOOBE_SUPPLIER > ??? = > Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new); > > public static void nullAndBoundsCheck(byte[] array, int offset, int > len) { > ??? Preconditions.checkFromIndexSize(offset, len, array.length, > AIOOBE_SUPPLIER); // implicit null check of array > } > > Prior art is really only the > java.lang.invoke.VarHandle.AIOOBE_SUPPLIER (which is used from > generated code, e.g. j.l.i.VarHandleInts); maybe it could be > refactored to some internal package for reuse. > > (I'd remove the explicit null check and lower-case the N in > NullAndBoundsCheck, regardless) > > Thanks! > > /Claes > > > On 2018-07-10 02:42, Valerie Peng wrote: >> Hi Tony, >> >> The purpose of the if-block is to ensure that >> ArrayIndexOutOfBoundsException is thrown instead of >> IndexOutOfBoundsException.? Objects.checkFromIndexSize(...) API is >> specified to throw IndexOutOfBoundsException which is more general >> and can be thrown when an index of some sort (such as to an array, to >> a string, or to a vector) is out of range. >> ArrayIndexOutOfBoundsException is a subclass of >> IndexOutOfBoundsException and is for array index out of bounds. >> >> Thanks, >> Valerie >> >> On 7/9/2018 3:14 PM, Anthony Scarpino wrote: >>> On 07/03/2018 02:03 PM, Valerie Peng wrote: >>>> Hi Tony, >>>> >>>> Would you have time to review this? Instead of doing the bounds >>>> check per block, the changes move the bounds check up one level. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179098 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8179098/webrev.00/ >>>> >>>> Thanks, >>>> Valerie >>> >>> >>> ArrayUtil.java: Line 48 >>> - It seems like your not throwing any >>> ArrayIndexOutOfBoundsExceptions, is that intentional? The method in >>> the try-catch seems to only throw IndexOutOfBoundsException, whole >>> if() seems confusing to me. >>> thanks >>> >>> Tony >> > From xuelei.fan at oracle.com Thu Jul 12 00:04:17 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jul 2018 17:04:17 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: Message-ID: <229b5338-8083-baca-bce7-9d725162c96f@oracle.com> Hi Simone, Thank for reporting this issue. To speed up the evaluation, would you mind send us the debug log (using system property "javax.net.debug=all")? Thanks, Xuelei On 7/11/2018 3:06 PM, Simone Bordet wrote: > Hi, > > I can see this (weird) behavior in SSLEngine for TLS 1.3 in JDK 11+21. > It's a simple new connection (no resumption) that performs a TLS 1.3 handshake. > The bytes numbers are those that I get, they may be different for > others depending on certificate size, etc. > > 1. Client wraps 394 bytes then goes into NEED_UNWRAP. > 2. Server unwraps 394 bytes then goes into NEED_TASK and then into NEED_WRAP. > 3. Server wraps (in 3 wraps) 160, 6 and 907 bytes then goes into NEED_UNWRAP. > 4. Client unwraps 160 bytes then goes into NEED_TASK and then into NEED_WRAP (?) > 5. Client wraps 6 bytes, then goes into NEED_UNWRAP. > 6. Client unwraps (in 2 unwraps) 6 and 907 bytes, then goes into > NEED_TASK and then into NEED_WRAP. > 7. Client wraps 58 bytes and goes into FINISHED (?) > 8. Server unwraps (in 2 unwraps) 6 and 58 bytes then goes into NEED_WRAP. > 9. Server wraps 72 bytes then goes into FINISHED. > 10. Client MUST unwrap those 72 bytes going again into FINISHED (which > already happened at 7). > > There are 2 things that I find weird: > > A) That at 4, the client goes into NEED_WRAP, even if it has not > finished to unwrap what the server sent. Apparently, it only goes into > NEED_WRAP to generate a CHANGE_CIPHER_SPEC (I am guessing from the > number of bytes generated), but then goes back into NEED_UNWRAP to > finish reading what the server sent. This is also not optimal as it > forces applications to do something with those 6 bytes: either put > them aside (additional data structures that may not be needed) or - > worse - write them to the server causing an additional write (after > all the effort TLS 1.3 put in to have a 1 RTT handshake). > I think that step 4 should go into NEED_UNWRAP, and that step 5 and > step 6 should be switched, so that the client would unwrap the 160, 6 > and 907 sent by the server, and only after wrapping the 6 and the 58. > To be clear, the current behavior is (u==unwrap, w=wrap): u160, w6, > u6, u907, w58. > I think it should be: u160, u6, u907, w6, w58. > > Is there any reason that the 6 bytes needs to be generated in-between > the processing of the frames sent by the server? > > B)That at 7 the client goes into FINISHED, but it is not finished > really: in fact it needs to perform step 10, but there is no > indication from the SSLEngine that it must do so. > Currently, step 7 says the client is finished and there is no clue > that it must unwrap those last 72 bytes. > I think step 7 should go into NEED_UNWRAP instead, and only at 10 go > into FINISHED. > > Thanks! > From xuelei.fan at oracle.com Thu Jul 12 04:47:11 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jul 2018 21:47:11 -0700 Subject: Code Review Request, JDK-8207029 Unable to use custom SSLEngine with default TrustManagerFactory after updating to JDK 11 b21 Message-ID: <2d533f47-a9ed-2309-a2a7-c7bff47b47fd@oracle.com> Hi, Please review the update: http://cr.openjdk.java.net/~xuelei/8207029/webrev.00/ It's an interesting user case of the TrustManagerFactory and KeyManagerFactory. The KeyManager or TrustManager implementation may be not implemented in the same provider as SSLSocket/SSLEngine. See also http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017536.html. Thanks, Xuelei From Alan.Bateman at oracle.com Thu Jul 12 06:53:21 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Jul 2018 07:53:21 +0100 Subject: Code Review Request, JDK-8207029 Unable to use custom SSLEngine with default TrustManagerFactory after updating to JDK 11 b21 In-Reply-To: <2d533f47-a9ed-2309-a2a7-c7bff47b47fd@oracle.com> References: <2d533f47-a9ed-2309-a2a7-c7bff47b47fd@oracle.com> Message-ID: On 12/07/2018 05:47, Xuelei Fan wrote: > Hi, > > Please review the update: > ??? http://cr.openjdk.java.net/~xuelei/8207029/webrev.00/ > > It's an interesting user case of the TrustManagerFactory and > KeyManagerFactory.? The KeyManager or TrustManager implementation may > be not implemented in the same provider as SSLSocket/SSLEngine. > > See also > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017536.html. Xuelei - is there follow-up work to develop some tests that use custom KeyManager or TrustManager implementations that are in different providers to the SSLEngine. I realize not many will do that but it seems easy to break these type of scenarios if we don't have tests. -Alan. From simone.bordet at gmail.com Thu Jul 12 09:03:34 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 12 Jul 2018 11:03:34 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: Message-ID: Hi, On Thu, Jul 12, 2018 at 12:06 AM Simone Bordet wrote: > > Hi, > > I can see this (weird) behavior in SSLEngine for TLS 1.3 in JDK 11+21. > It's a simple new connection (no resumption) that performs a TLS 1.3 handshake. > The bytes numbers are those that I get, they may be different for > others depending on certificate size, etc. > > 1. Client wraps 394 bytes then goes into NEED_UNWRAP. > 2. Server unwraps 394 bytes then goes into NEED_TASK and then into NEED_WRAP. > 3. Server wraps (in 3 wraps) 160, 6 and 907 bytes then goes into NEED_UNWRAP. > 4. Client unwraps 160 bytes then goes into NEED_TASK and then into NEED_WRAP (?) > 5. Client wraps 6 bytes, then goes into NEED_UNWRAP. > 6. Client unwraps (in 2 unwraps) 6 and 907 bytes, then goes into > NEED_TASK and then into NEED_WRAP. > 7. Client wraps 58 bytes and goes into FINISHED (?) > 8. Server unwraps (in 2 unwraps) 6 and 58 bytes then goes into NEED_WRAP. > 9. Server wraps 72 bytes then goes into FINISHED. > 10. Client MUST unwrap those 72 bytes going again into FINISHED (which > already happened at 7). > > There are 2 things that I find weird: > > A) That at 4, the client goes into NEED_WRAP, even if it has not > finished to unwrap what the server sent. Apparently, it only goes into > NEED_WRAP to generate a CHANGE_CIPHER_SPEC (I am guessing from the > number of bytes generated), but then goes back into NEED_UNWRAP to > finish reading what the server sent. This is also not optimal as it > forces applications to do something with those 6 bytes: either put > them aside (additional data structures that may not be needed) or - > worse - write them to the server causing an additional write (after > all the effort TLS 1.3 put in to have a 1 RTT handshake). > I think that step 4 should go into NEED_UNWRAP, and that step 5 and > step 6 should be switched, so that the client would unwrap the 160, 6 > and 907 sent by the server, and only after wrapping the 6 and the 58. > To be clear, the current behavior is (u==unwrap, w=wrap): u160, w6, > u6, u907, w58. > I think it should be: u160, u6, u907, w6, w58. > > Is there any reason that the 6 bytes needs to be generated in-between > the processing of the frames sent by the server? > > B)That at 7 the client goes into FINISHED, but it is not finished > really: in fact it needs to perform step 10, but there is no > indication from the SSLEngine that it must do so. > Currently, step 7 says the client is finished and there is no clue > that it must unwrap those last 72 bytes. > I think step 7 should go into NEED_UNWRAP instead, and only at 10 go > into FINISHED. In addition to what reported above, I would like to report also the weird behavior during the close handshake (i.e. when one side decides to close the connection). 1. client.closeOutbound() then goes into NEED_WRAP. 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING (?) 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. 4. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 5. Client unwraps 0 bytes (?) I think at step 2 the client should go into NEED_UNWRAP to read (at step 5) the server response to the close_notify. Instead, at step 5 the client unwraps 0 bytes so we are left with those 24 bytes from the server that applications need to discard. Also, I am not sure that the wrap result at step 2 and 3 should be CLOSED, perhaps OK is better? The server is actually closed at step 4, and the client at step 5. However, this is a minor issue. Attached the debug logs as you requested. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz -------------- next part -------------- A non-text attachment was scrubbed... Name: sslengine.log.gz Type: application/gzip Size: 15056 bytes Desc: not available URL: From xuelei.fan at oracle.com Thu Jul 12 13:33:22 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 06:33:22 -0700 Subject: Code Review Request, JDK-8207029 Unable to use custom SSLEngine with default TrustManagerFactory after updating to JDK 11 b21 In-Reply-To: References: <2d533f47-a9ed-2309-a2a7-c7bff47b47fd@oracle.com> Message-ID: Hi Alan, Yes, it is likely to introduce the issue again. We should consider a regression test. I just filed a follow-up bug in the JBS: https://bugs.openjdk.java.net/browse/JDK-8207174 Thanks, Xuelei On 7/11/2018 11:53 PM, Alan Bateman wrote: > On 12/07/2018 05:47, Xuelei Fan wrote: >> Hi, >> >> Please review the update: >> ??? http://cr.openjdk.java.net/~xuelei/8207029/webrev.00/ >> >> It's an interesting user case of the TrustManagerFactory and >> KeyManagerFactory.? The KeyManager or TrustManager implementation may >> be not implemented in the same provider as SSLSocket/SSLEngine. >> >> See also >> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017536.html. >> > Xuelei - is there follow-up work to develop some tests that use custom > KeyManager or TrustManager implementations that are in different > providers to the SSLEngine. I realize not many will do that but it seems > easy to break these type of scenarios if we don't have tests. > > -Alan. From xuelei.fan at oracle.com Thu Jul 12 14:33:42 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 07:33:42 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: Message-ID: Hi Simone, Thank you very much for the debug logs. Read more in-lines, please. On 7/12/2018 2:03 AM, Simone Bordet wrote: > Hi, > > On Thu, Jul 12, 2018 at 12:06 AM Simone Bordet wrote: >> >> Hi, >> >> I can see this (weird) behavior in SSLEngine for TLS 1.3 in JDK 11+21. >> It's a simple new connection (no resumption) that performs a TLS 1.3 handshake. >> The bytes numbers are those that I get, they may be different for >> others depending on certificate size, etc. >> >> 1. Client wraps 394 bytes then goes into NEED_UNWRAP. >> 2. Server unwraps 394 bytes then goes into NEED_TASK and then into NEED_WRAP. >> 3. Server wraps (in 3 wraps) 160, 6 and 907 bytes then goes into NEED_UNWRAP. >> 4. Client unwraps 160 bytes then goes into NEED_TASK and then into NEED_WRAP (?) >> 5. Client wraps 6 bytes, then goes into NEED_UNWRAP. >> 6. Client unwraps (in 2 unwraps) 6 and 907 bytes, then goes into >> NEED_TASK and then into NEED_WRAP. >> 7. Client wraps 58 bytes and goes into FINISHED (?) >> 8. Server unwraps (in 2 unwraps) 6 and 58 bytes then goes into NEED_WRAP. >> 9. Server wraps 72 bytes then goes into FINISHED. >> 10. Client MUST unwrap those 72 bytes going again into FINISHED (which >> already happened at 7). >> >> There are 2 things that I find weird: >> >> A) That at 4, the client goes into NEED_WRAP, even if it has not >> finished to unwrap what the server sent. Apparently, it only goes into >> NEED_WRAP to generate a CHANGE_CIPHER_SPEC (I am guessing from the >> number of bytes generated), but then goes back into NEED_UNWRAP to >> finish reading what the server sent. This is also not optimal as it >> forces applications to do something with those 6 bytes: either put >> them aside (additional data structures that may not be needed) or - >> worse - write them to the server causing an additional write (after >> all the effort TLS 1.3 put in to have a 1 RTT handshake). >> I think that step 4 should go into NEED_UNWRAP, and that step 5 and >> step 6 should be switched, so that the client would unwrap the 160, 6 >> and 907 sent by the server, and only after wrapping the 6 and the 58. >> To be clear, the current behavior is (u==unwrap, w=wrap): u160, w6, >> u6, u907, w58. >> I think it should be: u160, u6, u907, w6, w58. >> >> Is there any reason that the 6 bytes needs to be generated in-between >> the processing of the frames sent by the server? >> In order to mitigate the compatibility impact, the TLS 1.3 is implemented in the middlebox compatibility mode (See Section D.4, TLS 1.3 draft 28) in JDK. The 6 bytes message is the dummy change_cipher_spec record. More details, please refer to the "Middlebox Compatibility Mode" section in TLS 1.3 draft 28: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix-D.4 >> B)That at 7 the client goes into FINISHED, but it is not finished >> really: in fact it needs to perform step 10, but there is no >> indication from the SSLEngine that it must do so. >> Currently, step 7 says the client is finished and there is no clue >> that it must unwrap those last 72 bytes. >> I think step 7 should go into NEED_UNWRAP instead, and only at 10 go >> into FINISHED. TLS 1.3 allows handshake message delivered after the main handshake. The concept is called post-handshake message. Please refer to the "Post-Handshake Messages" for more details: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.6 In JDK 11, two post-handshake messages are supported, new session ticket and key/iv update. The 72 bytes in #9 and #10 are for the new session ticket. In JDK, the new session ticket post-handshake message is delivered immediately after the main handshake in server side. While for client side, it should be ready to accept the message at any time the main handshake complete. So, in #7, the FINISHED status means the main handshake complete. While in #10, the FINISHED status means that the post-handshake message get processed. I really concern about the compatibility impact. Did you run into problems with the new handshake message flow? > > In addition to what reported above, I would like to report also the > weird behavior during the close handshake (i.e. when one side decides > to close the connection). > > 1. client.closeOutbound() then goes into NEED_WRAP. > 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING (?) > 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. > 4. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > 5. Client unwraps 0 bytes (?) > > I think at step 2 the client should go into NEED_UNWRAP to read (at > step 5) the server response to the close_notify. In TLS 1.3, half-close policy is used. The server may not response with the close_notify for client close_notify request. See the "Closure Alerts" section for more details: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-6.1 It is a little bit complicated when moving from the duplex-close to half-close policy. In order to mitigate the compatibility impact, in JDK implementation, if the local send the close_notify, we choose to close the underlying socket as well if needed. But, if the peer send the close_notify, the unwrap() should be able to consume the bytes. It looks like a implementation bug to me. Would you please let us know if there are compatibility issues with the new half-close policy? Thanks, Xuelei > Instead, at step 5 the client unwraps 0 bytes so we are left with > those 24 bytes from the server that applications need to discard. > > Also, I am not sure that the wrap result at step 2 and 3 should be > CLOSED, perhaps OK is better? > The server is actually closed at step 4, and the client at step 5. > However, this is a minor issue. > > Attached the debug logs as you requested. > > Thanks! > From xuelei.fan at oracle.com Thu Jul 12 14:40:39 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 07:40:39 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: Message-ID: On 7/12/2018 7:33 AM, Xuelei Fan wrote: >> In addition to what reported above, I would like to report also the >> weird behavior during the close handshake (i.e. when one side decides >> to close the connection). >> >> 1. client.closeOutbound() then goes into NEED_WRAP. >> 2. Client wraps 24 bytes, result is CLOSED, then goes into >> NOT_HANDSHAKING (?) >> 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. >> 4. Server wraps 24 bytes, result is CLOSED, then goes into >> NOT_HANDSHAKING. >> 5. Client unwraps 0 bytes (?) >> >> I think at step 2 the client should go into NEED_UNWRAP to read (at >> step 5) the server response to the close_notify. > In TLS 1.3, half-close policy is used.? The server may not response with > the close_notify for client close_notify request.? See the "Closure > Alerts" section for more details: > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-6.1 > > It is a little bit complicated when moving from the duplex-close to > half-close policy.? In order to mitigate the compatibility impact, in > JDK implementation, if the local send the close_notify, we choose to > close the underlying socket as well if needed.? But, if the peer send > the close_notify, the unwrap() should be able to consume the bytes.? It > looks like a implementation bug to me. The issue is tracked in JBS: https://bugs.openjdk.java.net/browse/JDK-8207177 Xuelei From adam.petcher at oracle.com Thu Jul 12 15:50:04 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 12 Jul 2018 11:50:04 -0400 Subject: RFR 8206929: Check session context for TLS session resumption Message-ID: This change adds some checks for session resumption in TLS 1.3 to ensure that the resumed session is compatible with what is requested. Specifically, I'm adding checks for protocol version, cipher suite, client authentication, and signature schemes. There are also some minor whitespace formatting changes in PreSharedKeyExtension.java. This is a JDK 11 change, so please review soon. Webrev: http://cr.openjdk.java.net/~apetcher/8206929/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8206929 From xuelei.fan at oracle.com Thu Jul 12 16:45:10 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 09:45:10 -0700 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: References: Message-ID: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> A quick question about the update in HandshakeContext.java. + this.localSupportedSignAlgs = new ArrayList( + conContext.conSession.getLocalSupportedSignatureSchemes()); Why set the value here? The 'null' value of localSupportedSignAlgs has a special meaning that it has not been set. A few places depend on this special value. The above update may set it to empty if the session has not been established, and then prevent the proper setting of the value of it later. Xuelei On 7/12/2018 8:50 AM, Adam Petcher wrote: > This change adds some checks for session resumption in TLS 1.3 to ensure > that the resumed session is compatible with what is requested. > Specifically, I'm adding checks for protocol version, cipher suite, > client authentication, and signature schemes. There are also some minor > whitespace formatting changes in PreSharedKeyExtension.java. > > This is a JDK 11 change, so please review soon. > > Webrev: http://cr.openjdk.java.net/~apetcher/8206929/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8206929 > From adam.petcher at oracle.com Thu Jul 12 16:57:40 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 12 Jul 2018 12:57:40 -0400 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> Message-ID: <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> This value needs to be set when we create a PostHandshakeContext from a TransportContext. This only happens after the handshake is complete, so we should always have a session (right?). It may be better to set localSupportedSignAlgs in the constructor of PostHandshakeContext instead of where it is now. Would that address your concern? On 7/12/2018 12:45 PM, Xuelei Fan wrote: > A quick question about the update in HandshakeContext.java. > > +?? this.localSupportedSignAlgs = new ArrayList( > + conContext.conSession.getLocalSupportedSignatureSchemes()); > > Why set the value here?? The 'null' value of localSupportedSignAlgs > has a special meaning that it has not been set.? A few places depend > on this special value.? The above update may set it to empty if the > session has not been established, and then prevent the proper setting > of the value of it later. > > Xuelei > > On 7/12/2018 8:50 AM, Adam Petcher wrote: >> This change adds some checks for session resumption in TLS 1.3 to >> ensure that the resumed session is compatible with what is requested. >> Specifically, I'm adding checks for protocol version, cipher suite, >> client authentication, and signature schemes. There are also some >> minor whitespace formatting changes in PreSharedKeyExtension.java. >> >> This is a JDK 11 change, so please review soon. >> >> Webrev: http://cr.openjdk.java.net/~apetcher/8206929/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8206929 >> From xuelei.fan at oracle.com Thu Jul 12 17:02:08 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 10:02:08 -0700 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> Message-ID: Set it in PostHandshakeContext should be fine as the session should have been negotiated. Thanks, Xuelei On 7/12/2018 9:57 AM, Adam Petcher wrote: > This value needs to be set when we create a PostHandshakeContext from a > TransportContext. This only happens after the handshake is complete, so > we should always have a session (right?). > > It may be better to set localSupportedSignAlgs in the constructor of > PostHandshakeContext instead of where it is now. Would that address your > concern? > > > On 7/12/2018 12:45 PM, Xuelei Fan wrote: >> A quick question about the update in HandshakeContext.java. >> >> +?? this.localSupportedSignAlgs = new ArrayList( >> + conContext.conSession.getLocalSupportedSignatureSchemes()); >> >> Why set the value here?? The 'null' value of localSupportedSignAlgs >> has a special meaning that it has not been set.? A few places depend >> on this special value.? The above update may set it to empty if the >> session has not been established, and then prevent the proper setting >> of the value of it later. >> >> Xuelei >> >> On 7/12/2018 8:50 AM, Adam Petcher wrote: >>> This change adds some checks for session resumption in TLS 1.3 to >>> ensure that the resumed session is compatible with what is requested. >>> Specifically, I'm adding checks for protocol version, cipher suite, >>> client authentication, and signature schemes. There are also some >>> minor whitespace formatting changes in PreSharedKeyExtension.java. >>> >>> This is a JDK 11 change, so please review soon. >>> >>> Webrev: http://cr.openjdk.java.net/~apetcher/8206929/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206929 >>> > From sbordet at webtide.com Thu Jul 12 17:47:18 2018 From: sbordet at webtide.com (Simone Bordet) Date: Thu, 12 Jul 2018 19:47:18 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: Message-ID: Hi, On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote: > In order to mitigate the compatibility impact, the TLS 1.3 is > implemented in the middlebox compatibility mode (See Section D.4, TLS > 1.3 draft 28) in JDK. The 6 bytes message is the dummy > change_cipher_spec record. More details, please refer to the "Middlebox > Compatibility Mode" section in TLS 1.3 draft 28: > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix-D.4 Okay. But then those 6 bytes don't need to be generated immediately, right? The SSLEngine can finish to unwrap everything received by the server, and then wrap everything it needs to wrap. This will make simpler for applications to allocate buffers, recycle them, and in general implement TLS via SSLEngine in a simpler way (and more efficiently with less writes and/or data copies). > In JDK 11, two post-handshake messages are supported, new session ticket > and key/iv update. The 72 bytes in #9 and #10 are for the new session > ticket. In JDK, the new session ticket post-handshake message is > delivered immediately after the main handshake in server side. While > for client side, it should be ready to accept the message at any time > the main handshake complete. So, in #7, the FINISHED status means the > main handshake complete. While in #10, the FINISHED status means that > the post-handshake message get processed. > > I really concern about the compatibility impact. Did you run into > problems with the new handshake message flow? Yes, the Jetty CI integration went from 0 test failures in JDK 11+18 (and all previous JDK up to 8) to 500+ failures, all due to TLS 1.3. We will need to update our usage of SSLEngine heavily and disable TLS 1.3 in the meantime :( For example, FINISHED state was only every happening once before. Based on that, we could detect how many times a client was requesting renegotiations, and impose a limit on that (otherwise it would be an attack to the server). With the double FINISHED state in #7 and #10 we are not able to tell the difference based on the SSLEngine state alone. We would need to put "if (tls > 1.2) cannot_be_renegotiation_do_something_else()". What concerns me is that before SSLEngine was emitting instructions on what it needed an application to do in order to proceed the TLS handshake. You would call beginHandshake() on a client, and SSLEngine.getHandshakeStatus() would return NEED_WRAP, and the application would know that it needed to call wrap(). Now at step 7 it returns FINISHED, and SSLEngine.getHandshakeStatus() returns NOT_HANDSHAKING, so in principles there is nothing more to do. In a custom application protocol where a client opens a connection expecting to only send data to the server and never receiving data from the server, the client would never expect to read more bytes from the server for those post-handshake frames, because the SSLEngine does not tell. Having to put conditional code like "if (tls > 1.2) read_more_from_server_even_if_finished()" seems ugly. Would returning OK instead of FINISHED at step #10 be doable? After all, encrypting an empty string was always possible and there really is no difference for SSLEngine users: unwrapping those 72 bytes for the session ticket or the empty string would produce in both cases 0 decrypted bytes (it only changes the internal state of SSLEngine with the session ticket). > In TLS 1.3, half-close policy is used. The server may not response with > the close_notify for client close_notify request. See the "Closure > Alerts" section for more details: > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-6.1 In that section I read: "Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert." Given that, I expect that for close_notify, at step #2, the client goes into NEED_UNWRAP, as the server MUST send a close_notify too. Or at least that the server close_notify is consumed by the client at step #5, although this would again break the "SSLEngine state machine telling applications what to do". > It is a little bit complicated when moving from the duplex-close to > half-close policy. In order to mitigate the compatibility impact, in > JDK implementation, if the local send the close_notify, we choose to > close the underlying socket as well if needed. But, if the peer send > the close_notify, the unwrap() should be able to consume the bytes. It > looks like a implementation bug to me. Okay. > Would you please let us know if there are compatibility issues with the > new half-close policy? We've been massively struck by test failures, so I cannot tell which test had compatibility issues due to the close_notify differences. I suspect that most failures are due to the change of behavior at step #4. At this point, my gut feeling is that having a single codebase handling TLS 1.2 and TLS 1.3 would be difficult. I expect a few "if (tls > 1.2)" spread out in the code because now we need additional information that we did not need before because SSLEngine and its state machine was telling the application what next step was required but now it's not always the case anymore. I know that other SSLEngine users for widely used Java network servers are around in this list :) Would be great if they can feedback about whether JDK's SSLEngine with TLS 1.3 is working well for them. Thanks! -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. From rajan.halade at oracle.com Thu Jul 12 18:51:27 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 12 Jul 2018 11:51:27 -0700 Subject: RFR: 8199779: Add T-Systems, GlobalSign and Starfield services root certificates Message-ID: <2935b260-828b-3a75-ead3-79dd63585789@oracle.com> Please review this fix to add T-systems, GlobalSign, and Starfield services root certificates to cacerts. Webrev: http://cr.openjdk.java.net/~rhalade/8199779/webrev.00/ Thanks, Rajan From ivan.gerasimov at oracle.com Thu Jul 12 19:20:27 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 12 Jul 2018 12:20:27 -0700 Subject: RFR 8207031 : CKM_SSL3_PRE_MASTER_KEY_GEN used without need in P11RSACipher.class Message-ID: <9fc1e70d-a97f-d528-4d59-2908cd233784@oracle.com> Hello! I was reported that a 3rd-party PKCS11 provider stopped working correctly since integrating the fix for JDK-8134605. This is due to that a secret key is now generated via CKM_SSL3_PRE_MASTER_KEY_GEN even if it is going to be discarded (presumably, this is to avoid a time-attack.) Would you please help review a proposed fix: If the provider fails because it does not support CKM_SSL3_PRE_MASTER_KEY_GEN, and we do not need the newly generated key, then ignore the failure? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8207031 WEBREV: http://cr.openjdk.java.net/~igerasim/8207031/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From xuelei.fan at oracle.com Thu Jul 12 19:28:45 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 12:28:45 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: Message-ID: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> On 7/12/2018 10:47 AM, Simone Bordet wrote: > Hi, > > On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote: >> In order to mitigate the compatibility impact, the TLS 1.3 is >> implemented in the middlebox compatibility mode (See Section D.4, TLS >> 1.3 draft 28) in JDK. The 6 bytes message is the dummy >> change_cipher_spec record. More details, please refer to the "Middlebox >> Compatibility Mode" section in TLS 1.3 draft 28: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix-D.4 > > Okay. But then those 6 bytes don't need to be generated immediately, right? Per the TLS 1.3 specification: - The server sends a dummy change_cipher_spec record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest. and - If not offering early data, the client sends a dummy change_cipher_spec record (see the third paragraph of Section 5.1) immediately before its second flight. This may either be before its second ClientHello or before its encrypted handshake flight. If offering early data, the record is placed immediately after the first ClientHello. My read of the spec is that the dummy change_cipher_spec record is generated immediately after the ServerHello in server side, and before the 2nd flight in client side. > The SSLEngine can finish to unwrap everything received by the server, > and then wrap everything it needs to wrap. > This will make simpler for applications to allocate buffers, recycle > them, and in general implement TLS via SSLEngine in a simpler way (and > more efficiently with less writes and/or data copies). > The call to wrap() and unwrap() should follow the instructions of the handshake status (NEED_UNWRAP or NEED_WRAP). The sequence of wrap()/unwrap() is not expected to impact the usage. We may consider a option to turn off the middlebox compatibility mode if it helps Jetty. But the implementation code and the application should be ready to accept the fact that third party's implementation may be implemented in middlebox compatibility mode, and the change_cipher_spec record may still come in. >> In JDK 11, two post-handshake messages are supported, new session ticket >> and key/iv update. The 72 bytes in #9 and #10 are for the new session >> ticket. In JDK, the new session ticket post-handshake message is >> delivered immediately after the main handshake in server side. While >> for client side, it should be ready to accept the message at any time >> the main handshake complete. So, in #7, the FINISHED status means the >> main handshake complete. While in #10, the FINISHED status means that >> the post-handshake message get processed. >> >> I really concern about the compatibility impact. Did you run into >> problems with the new handshake message flow? > > Yes, the Jetty CI integration went from 0 test failures in JDK 11+18 > (and all previous JDK up to 8) to 500+ failures, all due to TLS 1.3. > We will need to update our usage of SSLEngine heavily and disable TLS > 1.3 in the meantime :( > Please feel free to send us the compatibility problems in this email alias. > For example, FINISHED state was only every happening once before. > Based on that, we could detect how many times a client was requesting > renegotiations, and impose a limit on that (otherwise it would be an > attack to the server). > With the double FINISHED state in #7 and #10 we are not able to tell > the difference based on the SSLEngine state alone. > We would need to put "if (tls > 1.2) > cannot_be_renegotiation_do_something_else()". > As the logic is related to TLS specification details, it might need to make some adjustment in Jetty as renegotiation has gone in TLS 1.3. > What concerns me is that before SSLEngine was emitting instructions on > what it needed an application to do in order to proceed the TLS > handshake. > You would call beginHandshake() on a client, and > SSLEngine.getHandshakeStatus() would return NEED_WRAP, and the > application would know that it needed to call wrap(). > It still works, I think. Normally, call beginHandshake(), and then check the handshake status for further operations. If the status if NEED_WRAP, call wrap(); if the status if NEED_UNWRAP(), call unwrap(); etc. > Now at step 7 it returns FINISHED, and SSLEngine.getHandshakeStatus() > returns NOT_HANDSHAKING, so in principles there is nothing more to do. It is still the same for TLS 1.3, right? The client can send application data now, I think. > In a custom application protocol where a client opens a connection > expecting to only send data to the server and never receiving data > from the server, the client would never expect to read more bytes from > the server for those post-handshake frames, because the SSLEngine does > not tell. > Having to put conditional code like "if (tls > 1.2) > read_more_from_server_even_if_finished()" seems ugly. > After #7 (FINISHED), if the client only send application data, but never call read again, it still works, right? The application don't have to read something, I think. in #10, you said, "Client MUST unwrap ...". Do you mean that the client cannot send application data without read/unwrap something? > Would returning OK instead of FINISHED at step #10 be doable? Post-handshaking may update the states of the connection. A signal is required if post-handshake happens. If we silently process the post-handshake messages, there might be some other problems. For example, the application is not aware the post-handshake authentication has completed if doing it silently. > After all, encrypting an empty string was always possible and there > really is no difference for SSLEngine users: unwrapping those 72 bytes > for the session ticket or the empty string would produce in both cases > 0 decrypted bytes (it only changes the internal state of SSLEngine > with the session ticket). > >> In TLS 1.3, half-close policy is used. The server may not response with >> the close_notify for client close_notify request. See the "Closure >> Alerts" section for more details: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-6.1 > > In that section I read: > "Each party MUST send a "close_notify" alert before closing its write > side of the connection, unless it has already sent some error alert." > > Given that, I expect that for close_notify, at step #2, the client > goes into NEED_UNWRAP, as the server MUST send a close_notify too. Half-close means that the server may not send the close_notify when it receive the client close_notify. It's a very tricky policy. The client close_notify only means the client want to close its writing side. The server may not send the close_notify if it doesn't want to close. If we have the client goes into NEED_UNWRAP, there is a potential dead waiting. Per the TLS 1.3 specification, the local can request to close its writing side, but it cannot to request to close the peer writing side. It means it is not defined about how to close the read side. It could lead to issues in practice. I had a question in the IETF TLS email list. But unfortunately, I did not get a ideal solution: https://www.ietf.org/mail-archive/web/tls/current/msg25581.html In order to countermeasure the issues, JDK will try to close the underlying socket if either side sends the close_notify message. But we still need to take care of third party's implementation which may not behave the same way. > Or at least that the server close_notify is consumed by the client at > step #5, although this would again break the "SSLEngine state machine > telling applications what to do". I think the following issues should be addressed: 1. the consuming of server close_notify issue 2. the NEED_WRAP after the CLOSEED status. I may miss something. Except #2, is there any other issue that break the "SSLEngine state machine telling applications what to do" rule? > >> It is a little bit complicated when moving from the duplex-close to >> half-close policy. In order to mitigate the compatibility impact, in >> JDK implementation, if the local send the close_notify, we choose to >> close the underlying socket as well if needed. But, if the peer send >> the close_notify, the unwrap() should be able to consume the bytes. It >> looks like a implementation bug to me. > > Okay. > >> Would you please let us know if there are compatibility issues with the >> new half-close policy? > > We've been massively struck by test failures, so I cannot tell which > test had compatibility issues due to the close_notify differences. > I suspect that most failures are due to the change of behavior at step #4. > > At this point, my gut feeling is that having a single codebase > handling TLS 1.2 and TLS 1.3 would be difficult. > I expect a few "if (tls > 1.2)" spread out in the code because now we > need additional information that we did not need before because > SSLEngine and its state machine was telling the application what next > step was required but now it's not always the case anymore. > It is not expected to dig into the TLS protocol version details in applications code. Otherwise, it would be a trouble once again if TLS 1.4 comes in the future. If an application depends on the protocol specification by itself, however, it may need some additional update when upgrade to new version. Thank you very much for sharing the evaluation with us. Let me see how we could have an improvement of the half-close issue (JDK-). > I know that other SSLEngine users for widely used Java network servers > are around in this list :) > Would be great if they can feedback about whether JDK's SSLEngine with > TLS 1.3 is working well for them. > Yes, please feel free to share your ideas. Thanks, Xuelei > Thanks! > > -- > Simone Bordet > ---- > http://cometd.org > http://webtide.com > Developer advice, training, services and support > from the Jetty & CometD experts. > From david.lloyd at redhat.com Thu Jul 12 20:04:39 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 12 Jul 2018 15:04:39 -0500 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> Message-ID: On Thu, Jul 12, 2018 at 2:30 PM Xuelei Fan wrote: > On 7/12/2018 10:47 AM, Simone Bordet wrote: > > On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote: [...] > >> In TLS 1.3, half-close policy is used. The server may not response with > >> the close_notify for client close_notify request. See the "Closure > >> Alerts" section for more details: > >> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-6.1 > > > > In that section I read: > > "Each party MUST send a "close_notify" alert before closing its write > > side of the connection, unless it has already sent some error alert." > > > > Given that, I expect that for close_notify, at step #2, the client > > goes into NEED_UNWRAP, as the server MUST send a close_notify too. [...] > Per the TLS 1.3 specification, the local can request to close its > writing side, but it cannot to request to close the peer writing side. > It means it is not defined about how to close the read side. It could > lead to issues in practice. I had a question in the IETF TLS email > list. But unfortunately, I did not get a ideal solution: > https://www.ietf.org/mail-archive/web/tls/current/msg25581.html > > In order to countermeasure the issues, JDK will try to close the > underlying socket if either side sends the close_notify message. Please forgive my interjection - does this not explicitly violate the half-close policy? The socket should not be closed until close_notify is both received (which means that read-shutdown is allowed) and sent (after which write-shutdown may be performed), should it not? > > At this point, my gut feeling is that having a single codebase > > handling TLS 1.2 and TLS 1.3 would be difficult. Is this feeling due to the half-closed situation? Because it's my firm belief that an TLS 1.2 implementation which treats half-closed in the manner specified by TLS 1.3 cannot be shown (from the perspective of an outside observer) to be in violation of the specification, and furthermore, _not_ doing so may represent a theoretical existent security risk. Put another way, imagine that my endpoint receives data and then sends data. Now imagine that the receive side immediately receives close_notify after its data is processed but before the send (response) begins. This obviously will terminate the connection before the data is output. Now imagine that the close_notify is completely contained in a single TCP packet, and that packet is (for whatever reason) delayed on the network until my send is complete. The OpenJDK TLS stack closes the socket at the right time (from my perspective), after both receive and send completed correctly. This delay has caused a material behavior change of my application, which is not a desirable effect. Two different behaviors, with the only input difference being one of timing. Imagine again now that the TLS 1.2 stack would not immediately send a close_notify, but instead would follow the half-close model as specified in TLS 1.3. As far as the *peer* is aware, my endpoint is conformant, because the peer cannot possibly differentiate between the TLS stack deferring shutdown to the application versus the close_notify message being delayed on the network. And, a bad actor can no longer affect the behavior of the application by delaying packets. These reasons were, without a doubt, considerations when the rules were changed for TLS 1.3. Also another important consideration was probably the observation that OpenSSL *already* appears to behave in this manner. OpenJDK's behavior has always IMO been clearly incorrect in this regard, despite the wording of the specification, and seeing this belief borne out by the changes in the TLS 1.3 spec is somewhat vindicating in this regard. But more importantly, I think this represents a chance to fix this long-standing bad behavior of the JDK. -- - DML From sbordet at webtide.com Thu Jul 12 20:09:30 2018 From: sbordet at webtide.com (Simone Bordet) Date: Thu, 12 Jul 2018 22:09:30 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> Message-ID: Hi, On Thu, Jul 12, 2018 at 10:05 PM David Lloyd wrote: > But more importantly, I think this > represents a chance to fix this long-standing bad behavior of the JDK. Indeed! Another thing I was about to complain is that SSLSocket.shutdownOutput() still throws: UnsupportedOperationException("The method shutdownOutput() is not supported in SSLSocket"); Thanks! -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. From simone.bordet at gmail.com Thu Jul 12 20:17:00 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 12 Jul 2018 22:17:00 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> Message-ID: Hi, On Thu, Jul 12, 2018 at 9:29 PM Xuelei Fan wrote: > Per the TLS 1.3 specification: > - The server sends a dummy change_cipher_spec record immediately > after its first handshake message. This may either be after a > ServerHello or a HelloRetryRequest. > > and > - If not offering early data, the client sends a dummy > change_cipher_spec record (see the third paragraph of Section 5.1) > immediately before its second flight. This may either be before > its second ClientHello or before its encrypted handshake flight. > If offering early data, the record is placed immediately after the > first ClientHello. > > My read of the spec is that the dummy change_cipher_spec record is > generated immediately after the ServerHello in server side, and before > the 2nd flight in client side. The spec is about *sending*, while I'm about *generating*. Currently: - Server wraps 160, 6 and 907 in 3 wraps. - Server *sends* the 1073 bytes in 1 TCP write - Client unwraps 160, then goes into NEED_WRAP - Client wraps 6, then goes again into NEED_UNWRAP to finish with the 6 and 907 received by the server. What I'm suggesting: - Server wraps 160, 6 and 907 in 3 wraps. - Server *sends* the 1073 (160+6+907) bytes in 1 TCP write - Client unwraps 160, stays in NEED_UNWRAP, unwraps the 6, unwraps the 907, then goes into NEED_WRAP - Client wraps 6 and 58 - Client *sends* the 64 (6+58) bytes in 1 TCP write. The 6 bytes of the dummy change_cipher_spec are *sent* just after receiving the ServerHello in both cases, they are just *generated* at different times. By having all the unwraps() consecutive and all the wraps() consecutive you can enable a number of optimizations I described earlier. Imagine a client that would perform a TCP *send* every time the state moves away from NEED_WRAP. Currently it would: 1. TCP send for ClientHello 2. Reads 1073 from server 3. Unwrap 160, then NEED_WRAP 4. Generate 6, then NEED_UNWRAP 5. TCP send the 6 bytes 6. Unwrap 6 and 907, then NEED_WRAP 7. Generate 58 then FINISHED 8 TCP send the 58 bytes. You can see that the client issues 3 TCP sends. With what I am suggesting, the client would only issue 2 TCP sends, which seems more in line with the efforts in TLS 1.3 to be more efficient. It would just be a matter of *generating* those 6 bytes a bit later, *after* having fully unwrapped the ServerHello. > We may consider a option to turn off the middlebox compatibility mode if > it helps Jetty. No need to. > But the implementation code and the application should > be ready to accept the fact that third party's implementation may be > implemented in middlebox compatibility mode, and the change_cipher_spec > record may still come in. See above, it's not about processing the dummy change_cipher_spec, it's just about generating it a little later. > After #7 (FINISHED), if the client only send application data, but never > call read again, it still works, right? The application don't have to > read something, I think. Sure, it just can't take advantage of session resumption though. The client never knows that there are post-handshake messages to read because SSLEgine did not tell. SSLEngine just said FINISHED and NOT_HANDSHAKING. However, I see your point. Handshake messages could come at any time, just that this one seems more part of the initial handshake, especially if it's about session resumption. > in #10, you said, "Client MUST unwrap ...". Do you mean that the client > cannot send application data without read/unwrap something? It can send data, but won't be good to leave unprocessed bytes around. The application would not know that there is stuff to read from the network and to process as post-handshake messages. It may never read from the network again. > Half-close means that the server may not send the close_notify when it > receive the client close_notify. It's a very tricky policy. The client > close_notify only means the client want to close its writing side. The > server may not send the close_notify if it doesn't want to close. If we > have the client goes into NEED_UNWRAP, there is a potential dead waiting. Good point. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Thu Jul 12 21:09:57 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 14:09:57 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> Message-ID: <033ecba8-35ff-e77d-5a9d-0d2a015c6d95@oracle.com> On 7/12/2018 1:04 PM, David Lloyd wrote: > On Thu, Jul 12, 2018 at 2:30 PM Xuelei Fan wrote: >> On 7/12/2018 10:47 AM, Simone Bordet wrote: >>> On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote: > [...] >>>> In TLS 1.3, half-close policy is used. The server may not response with >>>> the close_notify for client close_notify request. See the "Closure >>>> Alerts" section for more details: >>>> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-6.1 >>> >>> In that section I read: >>> "Each party MUST send a "close_notify" alert before closing its write >>> side of the connection, unless it has already sent some error alert." >>> >>> Given that, I expect that for close_notify, at step #2, the client >>> goes into NEED_UNWRAP, as the server MUST send a close_notify too. > [...] >> Per the TLS 1.3 specification, the local can request to close its >> writing side, but it cannot to request to close the peer writing side. >> It means it is not defined about how to close the read side. It could >> lead to issues in practice. I had a question in the IETF TLS email >> list. But unfortunately, I did not get a ideal solution: >> https://www.ietf.org/mail-archive/web/tls/current/msg25581.html >> >> In order to countermeasure the issues, JDK will try to close the >> underlying socket if either side sends the close_notify message. > > Please forgive my interjection - does this not explicitly violate the > half-close policy? The socket should not be closed until close_notify > is both received (which means that read-shutdown is allowed) and sent > (after which write-shutdown may be performed), should it not? > In TLS 1.3 closure, receiving of the close_notify is not required: "... Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation." TLS 1.2 also has similar specification: "It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection." My reading the spec, the peer MUST send the close_notify, but it is not required to close the connection. If the socket cannot be closed until close_notify get received, the local may never have a chance to close the socket unless the peer agrees. It does not sound like to me. The compatibility impact could be serious as previous application work in a duplex-close manner. 1. start and establish a TLS connection. 2. client call close(), and the server will response with a close_notify in TLS 1.2. the TLS connection can be closed gracefully. While for TLS 1.3, #2 does not work if the client calling of close() closes the writing side only, and leave the reading side open. I see the benefits of half-close. I'm open to hear a better solution to take the benefit of half-close and avoid the compatibility issue. I raised a similar question in the TLS mailing list: https://www.ietf.org/mail-archive/web/tls/current/msg25581.html A new close_request alert might be able to solve the issue. But I had no strong user case in practice about why we cannot close the underlying TCP socket if we don't want to read. There was on census for the discussion in the IETF TLS mailing list, and the request was deferred. Thanks, Xuelei >>> At this point, my gut feeling is that having a single codebase >>> handling TLS 1.2 and TLS 1.3 would be difficult. > > Is this feeling due to the half-closed situation? Because it's my > firm belief that an TLS 1.2 implementation which treats half-closed in > the manner specified by TLS 1.3 cannot be shown (from the perspective > of an outside observer) to be in violation of the specification, and > furthermore, _not_ doing so may represent a theoretical existent > security risk. > > Put another way, imagine that my endpoint receives data and then sends > data. Now imagine that the receive side immediately receives > close_notify after its data is processed but before the send > (response) begins. This obviously will terminate the connection > before the data is output. > > Now imagine that the close_notify is completely contained in a single > TCP packet, and that packet is (for whatever reason) delayed on the > network until my send is complete. The OpenJDK TLS stack closes the > socket at the right time (from my perspective), after both receive and > send completed correctly. This delay has caused a material behavior > change of my application, which is not a desirable effect. Two > different behaviors, with the only input difference being one of > timing. > > Imagine again now that the TLS 1.2 stack would not immediately send a > close_notify, but instead would follow the half-close model as > specified in TLS 1.3. As far as the *peer* is aware, my endpoint is > conformant, because the peer cannot possibly differentiate between the > TLS stack deferring shutdown to the application versus the > close_notify message being delayed on the network. And, a bad actor > can no longer affect the behavior of the application by delaying > packets. > > These reasons were, without a doubt, considerations when the rules > were changed for TLS 1.3. Also another important consideration was > probably the observation that OpenSSL *already* appears to behave in > this manner. OpenJDK's behavior has always IMO been clearly incorrect > in this regard, despite the wording of the specification, and seeing > this belief borne out by the changes in the TLS 1.3 spec is somewhat > vindicating in this regard. But more importantly, I think this > represents a chance to fix this long-standing bad behavior of the JDK. > From xuelei.fan at oracle.com Thu Jul 12 21:14:49 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 14:14:49 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> Message-ID: On 7/12/2018 1:09 PM, Simone Bordet wrote: > Hi, > On Thu, Jul 12, 2018 at 10:05 PM David Lloyd wrote: >> But more importantly, I think this >> represents a chance to fix this long-standing bad behavior of the JDK. > > Indeed! > > Another thing I was about to complain is that > SSLSocket.shutdownOutput() still throws: > UnsupportedOperationException("The method shutdownOutput() is not > supported in SSLSocket"); > This happens before JDK 11 B20, right? Thanks, Xuelei From sbordet at webtide.com Thu Jul 12 21:26:17 2018 From: sbordet at webtide.com (Simone Bordet) Date: Thu, 12 Jul 2018 23:26:17 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> Message-ID: Hi, On Thu, Jul 12, 2018 at 11:15 PM Xuelei Fan wrote: > > On 7/12/2018 1:09 PM, Simone Bordet wrote: > > Hi, > > On Thu, Jul 12, 2018 at 10:05 PM David Lloyd wrote: > >> But more importantly, I think this > >> represents a chance to fix this long-standing bad behavior of the JDK. > > > > Indeed! > > > > Another thing I was about to complain is that > > SSLSocket.shutdownOutput() still throws: > > UnsupportedOperationException("The method shutdownOutput() is not > > supported in SSLSocket"); > > > This happens before JDK 11 B20, right? No, it still happens on 11+21. Cheers -- Simone Bordet ---- http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts. From simone.bordet at gmail.com Thu Jul 12 21:39:52 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 12 Jul 2018 23:39:52 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: <033ecba8-35ff-e77d-5a9d-0d2a015c6d95@oracle.com> References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <033ecba8-35ff-e77d-5a9d-0d2a015c6d95@oracle.com> Message-ID: Hi, On Thu, Jul 12, 2018 at 11:10 PM Xuelei Fan wrote: > In TLS 1.3 closure, receiving of the close_notify is not required: > "... Both parties need not wait to receive a > "close_notify" alert before closing their read side of the > connection, though doing so would introduce the possibility of > truncation." > > TLS 1.2 also has similar specification: > "It is not required for the initiator > of the close to wait for the responding close_notify alert before > closing the read side of the connection." > > My reading the spec, the peer MUST send the close_notify, but it is not > required to close the connection. > > If the socket cannot be closed until close_notify get received, the > local may never have a chance to close the socket unless the peer > agrees. It does not sound like to me. The compatibility impact could > be serious as previous application work in a duplex-close manner. > 1. start and establish a TLS connection. > 2. client call close(), and the server will response with a close_notify > in TLS 1.2. the TLS connection can be closed gracefully. > > While for TLS 1.3, #2 does not work if the client calling of close() > closes the writing side only, and leave the reading side open. > > I see the benefits of half-close. I'm open to hear a better solution to > take the benefit of half-close and avoid the compatibility issue. Even in TLS 1.2 you cannot be sure that the server will send the close_notify (e.g. bad server). The half close problem is present in TCP, WebSocket, etc. and it's typically solved with (idle) timeouts. Client sends the close_notify, then reads, hoping to see the close_notify from the server; if it does not see it, it closes the raw socket after a timeout. The timeout could account for receiving data (i.e. it is reset if application data arrives), or not. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Thu Jul 12 23:05:26 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 16:05:26 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <033ecba8-35ff-e77d-5a9d-0d2a015c6d95@oracle.com> Message-ID: <6eabfdee-e7c3-be99-501b-38edd054d344@oracle.com> On 7/12/2018 2:39 PM, Simone Bordet wrote: > Hi, > > On Thu, Jul 12, 2018 at 11:10 PM Xuelei Fan wrote: >> In TLS 1.3 closure, receiving of the close_notify is not required: >> "... Both parties need not wait to receive a >> "close_notify" alert before closing their read side of the >> connection, though doing so would introduce the possibility of >> truncation." >> >> TLS 1.2 also has similar specification: >> "It is not required for the initiator >> of the close to wait for the responding close_notify alert before >> closing the read side of the connection." >> >> My reading the spec, the peer MUST send the close_notify, but it is not >> required to close the connection. >> >> If the socket cannot be closed until close_notify get received, the >> local may never have a chance to close the socket unless the peer >> agrees. It does not sound like to me. The compatibility impact could >> be serious as previous application work in a duplex-close manner. >> 1. start and establish a TLS connection. >> 2. client call close(), and the server will response with a close_notify >> in TLS 1.2. the TLS connection can be closed gracefully. >> >> While for TLS 1.3, #2 does not work if the client calling of close() >> closes the writing side only, and leave the reading side open. >> >> I see the benefits of half-close. I'm open to hear a better solution to >> take the benefit of half-close and avoid the compatibility issue. > > Even in TLS 1.2 you cannot be sure that the server will send the > close_notify (e.g. bad server). Yes, but normally, the server MUST respond with a close_notify. > The half close problem is present in TCP, WebSocket, etc. and it's > typically solved with (idle) timeouts. > > Client sends the close_notify, then reads, hoping to see the > close_notify from the server; if it does not see it, it closes the raw > socket after a timeout. > The timeout could account for receiving data (i.e. it is reset if > application data arrives), or not. > I will think more about this proposal. Thanks, Xuelei From bradford.wetmore at oracle.com Fri Jul 13 00:06:00 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 12 Jul 2018 17:06:00 -0700 Subject: Code Review Request, JDK-8207029 Unable to use custom SSLEngine with default TrustManagerFactory after updating to JDK 11 b21 In-Reply-To: References: <2d533f47-a9ed-2309-a2a7-c7bff47b47fd@oracle.com> Message-ID: The code itself looks good, but I didn't see a regression tests. Is this what JDK-8207174 will be for? On 7/11/2018 11:53 PM, Alan Bateman wrote: > On 12/07/2018 05:47, Xuelei Fan wrote: >> It's an interesting user case of the TrustManagerFactory and >> KeyManagerFactory.? The KeyManager or TrustManager implementation may >> be not implemented in the same provider as SSLSocket/SSLEngine. >> >> See also >> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017536.html. >> > Xuelei - is there follow-up work to develop some tests that use custom > KeyManager or TrustManager implementations that are in different > providers to the SSLEngine. I realize not many will do that but it seems > easy to break these type of scenarios if we don't have tests. If I understand your question correctly, custom KM/TM are quite common. I routinely write custom impls to wrap functionality around the behavior of the stock TM/KM. e.g. outputting debug information. class MyTM extends X509TrustManager { private final X509TrustManager tm; MyTM(X509TrustManager tm) { theTM = tm; } checkTrusted(args) System.out.println(args); tm.checkTrusts(args) } } Brad From xuelei.fan at oracle.com Fri Jul 13 00:49:44 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 12 Jul 2018 17:49:44 -0700 Subject: Code Review Request, JDK-8207029 Unable to use custom SSLEngine with default TrustManagerFactory after updating to JDK 11 b21 In-Reply-To: References: <2d533f47-a9ed-2309-a2a7-c7bff47b47fd@oracle.com> Message-ID: On 7/12/2018 5:06 PM, Bradford Wetmore wrote: > The code itself looks good, but I didn't see a regression tests.? Is > this what JDK-8207174 will be for? > No, I did not have a regression test in this update. I asked the bug reporter helped for the testing, and passed. However, we definitely need a regression test as it is likely to happen again in the future. JDK-8207174 is used for the following up test development. Thanks, Xuelei > On 7/11/2018 11:53 PM, Alan Bateman wrote: >> On 12/07/2018 05:47, Xuelei Fan wrote: > >>> It's an interesting user case of the TrustManagerFactory and >>> KeyManagerFactory.? The KeyManager or TrustManager implementation may >>> be not implemented in the same provider as SSLSocket/SSLEngine. >>> >>> See also >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017536.html. >>> >> Xuelei - is there follow-up work to develop some tests that use custom >> KeyManager or TrustManager implementations that are in different >> providers to the SSLEngine. I realize not many will do that but it >> seems easy to break these type of scenarios if we don't have tests. > > If I understand your question correctly, custom KM/TM are quite common. > I routinely write custom impls to wrap functionality around the behavior > of the stock TM/KM.? e.g. outputting debug information. > > class MyTM extends X509TrustManager { > ??? private final X509TrustManager tm; > ??? MyTM(X509TrustManager tm) { > ??????? theTM = tm; > ??? } > ??? checkTrusted(args) > ??????? System.out.println(args); > ??????? tm.checkTrusts(args) > ??? } > } > > Brad > From sha.jiang at oracle.com Fri Jul 13 01:15:33 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 13 Jul 2018 09:15:33 +0800 Subject: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found In-Reply-To: <905d69d6-1112-0b53-9124-f53c783fa803@oracle.com> References: <905d69d6-1112-0b53-9124-f53c783fa803@oracle.com> Message-ID: Could the new patch be reviewed? http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ Thanks! John On 2018/7/9 15:38, sha.jiang at oracle.com wrote: > Hi Thomas, > Thanks for your testing. > > I'm not sure that's a reasonable case. > From my view, PKCS11Test.java simply checks if the NSS library > directory exists. > But it looks unnecessary to check every library file. > In fact, if removing libnss3 or libsoftokn3's dependencies, like > libnssutil3, the test also fails. > > However, I still re-checked my previous solution, and made a new > webrev [1]. > The constant badNSSVersion in PKCS11Test.java may not be fine. > The static field nss_library in PKCS11Test.java can be softokn3 or > nss3 for different tests. > badNSSVersion should be checked after the target nss library is > determined. > And this checking should happen before the real testing, especially > before security manager is enabled. > So, a new extension method, exactly PKCS11Test::skipTest, was > introduced, and the affected tests were modified accordingly. > > [1] http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ > > Best regards, > John Jiang > > On 2018/7/4 14:15, Thomas St?fe wrote: >> Hi, >> >> Unfortunately this is not enough. >> >> Running tests with your patch and NSS libs disabled (I renamed >> libsoftokn3.so) yields the following errors: >> >> sun/security/pkcs11/Secmod/AddPrivateKey.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/AddTrustedCert.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/Crypto.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/GetPrivateKey.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/JksSetPrivateKey.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/LoadKeystore.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/TestNssDbSqlite.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/TrustAnchors.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> >> >> Excerpt from TestNssDbSqlite.jtr: >> >> ----------messages:(3/98)---------- >> command: build TestNssDbSqlite >> reason: Named class compiled on demand >> elapsed time (seconds): 0.0 >> result: Passed. All files up to date >> >> #section:main >> ----------messages:(5/721)---------- >> command: main TestNssDbSqlite >> reason: User specified action: run main/othervm/timeout=120 >> TestNssDbSqlite >> Mode: othervm [/othervm specified] >> Additional options from @modules: --add-modules >> java.base,jdk.crypto.cryptoki --add-exports >> java.base/sun.security.rsa=ALL-UNNAMED --add-exports >> java.base/sun.security.provider=ALL-UNNAMED --add-exports >> java.base/sun.security.jca=ALL-UNNAMED --add-exports >> java.base/sun.security.tools.keytool=ALL-UNNAMED --add-exports >> java.base/sun.security.x509=ALL-UNNAMED --add-exports >> java.base/com.sun.crypto.provider=ALL-UNNAMED --add-exports >> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED --add-opens >> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED >> elapsed time (seconds): 0.445 >> ----------configuration:(11/604)---------- >> Boot Layer >> ?? add modules: java.base jdk.crypto.cryptoki >> ?? add exports: java.base/com.sun.crypto.provider ALL-UNNAMED >> ??????????????? java.base/sun.security.jca ALL-UNNAMED >> ??????????????? java.base/sun.security.provider ALL-UNNAMED >> ??????????????? java.base/sun.security.rsa ALL-UNNAMED >> ??????????????? java.base/sun.security.tools.keytool ALL-UNNAMED >> ??????????????? java.base/sun.security.x509 ALL-UNNAMED >> ??????????????? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >> ?? add opens:?? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >> >> ----------System.out:(1/64)---------- >> Warning: can't find NSS librarys on this machine, skipping test >> ----------System.err:(25/1633)---------- >> java.security.ProviderException: Could not initialize NSS >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:218) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) >> at PKCS11Test.getSunPKCS11(PKCS11Test.java:152) >> at TestNssDbSqlite.initializeProvider(TestNssDbSqlite.java:121) >> at TestNssDbSqlite.initialize(TestNssDbSqlite.java:112) >> at TestNssDbSqlite.main(TestNssDbSqlite.java:67) >> 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:115) >> at java.base/java.lang.Thread.run(Thread.java:834) >> Caused by: java.io.IOException: NSS initialization failed >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:234) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:213) >> ... 14 more >> >> Kind Regards, Thomas >> >> >> On Wed, Jul 4, 2018 at 7:36 AM,? wrote: >>> Hi, >>> If NSS libs are unavailable, PKCS11 tests fail when checking NSS >>> version. >>> This patch tries to fix this issue. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206258 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.00/ >>> >>> Best regards, >>> John Jiang >>> > > From valerie.peng at oracle.com Fri Jul 13 02:01:41 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 12 Jul 2018 19:01:41 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: Message-ID: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> Hi Max, The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. Thanks, Valerie On 7/10/2018 7:16 PM, Weijun Wang wrote: > Hi Valerie > > About "it *may* return", do you mean it could also return null? My understanding is no. > > Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? > > Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. > > Thanks > Max > > >> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >> >> Hi Brad, >> >> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >> No source code changes, but just updating javadoc to mention the possible failure case. >> Otherwise, JCK team expects a parameter object or null being returned. >> I filed a CSR to track the javadoc clarification. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >> >> Thanks, >> Valerie >> >> >> From weijun.wang at oracle.com Fri Jul 13 02:23:31 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 13 Jul 2018 10:23:31 +0800 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> Message-ID: > On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: > > Hi Max, > > The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. Sure. > > The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. > > As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. I assume other getParameters() had not added it is because it happened they can return one. While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. For example, @throws SecurityException for File/Files operations. Thanks Max > > Thanks, > Valerie > > On 7/10/2018 7:16 PM, Weijun Wang wrote: >> Hi Valerie >> >> About "it *may* return", do you mean it could also return null? My understanding is no. >> >> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >> >> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >> >> Thanks >> Max >> >> >>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>> >>> Hi Brad, >>> >>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>> No source code changes, but just updating javadoc to mention the possible failure case. >>> Otherwise, JCK team expects a parameter object or null being returned. >>> I filed a CSR to track the javadoc clarification. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>> >>> Thanks, >>> Valerie >>> >>> >>> > From sha.jiang at oracle.com Fri Jul 13 05:39:47 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 13 Jul 2018 13:39:47 +0800 Subject: RFR[12] JDK-8206443: Update security libs manual test to cope with removal of javac -source/-target 6 Message-ID: Hi, JDK-8028563 has removed javac support for 6/1.6 source and target, so the following tests has to be updated accordingly. javax/net/ssl/compatibility/Compatibility.java sun/security/tools/jarsigner/compatibility/Compatibility.java In addition, this fix also makes javax/net/ssl/compatibility/Compatibility.java can work with JDK 12 builds. Webrev: http://cr.openjdk.java.net/~jjiang/8206443/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8206443 Best regards, John Jiang From sean.mullan at oracle.com Fri Jul 13 12:10:00 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jul 2018 08:10:00 -0400 Subject: RFR: 8199779: Add T-Systems, GlobalSign and Starfield services root certificates In-Reply-To: <2935b260-828b-3a75-ead3-79dd63585789@oracle.com> References: <2935b260-828b-3a75-ead3-79dd63585789@oracle.com> Message-ID: Looks good. --Sean On 7/12/18 2:51 PM, Rajan Halade wrote: > Please review this fix to add T-systems, GlobalSign, and Starfield > services root certificates to cacerts. > > Webrev: http://cr.openjdk.java.net/~rhalade/8199779/webrev.00/ > > Thanks, > Rajan From xuelei.fan at oracle.com Fri Jul 13 13:31:02 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 13 Jul 2018 06:31:02 -0700 Subject: RFR[12] JDK-8206443: Update security libs manual test to cope with removal of javac -source/-target 6 In-Reply-To: References: Message-ID: <10ac91ee-5f23-cca0-f28b-3650bab24437@oracle.com> Looks fine to me. Thanks, Xuelei On 7/12/2018 10:39 PM, sha.jiang at oracle.com wrote: > Hi, > JDK-8028563 has removed javac support for 6/1.6 source and target, so > the following tests has to be updated accordingly. > javax/net/ssl/compatibility/Compatibility.java > sun/security/tools/jarsigner/compatibility/Compatibility.java > > In addition, this fix also makes > javax/net/ssl/compatibility/Compatibility.java can work with JDK 12 builds. > > Webrev: http://cr.openjdk.java.net/~jjiang/8206443/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8206443 > > Best regards, > John Jiang > From xuelei.fan at oracle.com Fri Jul 13 13:45:56 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 13 Jul 2018 06:45:56 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> Message-ID: <7998962c-9060-b1cd-8116-17da18981796@oracle.com> On 7/12/2018 1:17 PM, Simone Bordet wrote: > Hi, > > On Thu, Jul 12, 2018 at 9:29 PM Xuelei Fan wrote: >> Per the TLS 1.3 specification: >> - The server sends a dummy change_cipher_spec record immediately >> after its first handshake message. This may either be after a >> ServerHello or a HelloRetryRequest. >> >> and >> - If not offering early data, the client sends a dummy >> change_cipher_spec record (see the third paragraph of Section 5.1) >> immediately before its second flight. This may either be before >> its second ClientHello or before its encrypted handshake flight. >> If offering early data, the record is placed immediately after the >> first ClientHello. >> >> My read of the spec is that the dummy change_cipher_spec record is >> generated immediately after the ServerHello in server side, and before >> the 2nd flight in client side. > > The spec is about *sending*, while I'm about *generating*. > > Currently: > - Server wraps 160, 6 and 907 in 3 wraps. > - Server *sends* the 1073 bytes in 1 TCP write > - Client unwraps 160, then goes into NEED_WRAP > - Client wraps 6, then goes again into NEED_UNWRAP to finish with the > 6 and 907 received by the server. > > What I'm suggesting: > - Server wraps 160, 6 and 907 in 3 wraps. > - Server *sends* the 1073 (160+6+907) bytes in 1 TCP write > - Client unwraps 160, stays in NEED_UNWRAP, unwraps the 6, unwraps the > 907, then goes into NEED_WRAP > - Client wraps 6 and 58 > - Client *sends* the 64 (6+58) bytes in 1 TCP write. > > The 6 bytes of the dummy change_cipher_spec are *sent* just after > receiving the ServerHello in both cases, they are just *generated* at > different times. > > By having all the unwraps() consecutive and all the wraps() > consecutive you can enable a number of optimizations I described > earlier. > > Imagine a client that would perform a TCP *send* every time the state > moves away from NEED_WRAP. > Currently it would: > 1. TCP send for ClientHello > 2. Reads 1073 from server > 3. Unwrap 160, then NEED_WRAP > 4. Generate 6, then NEED_UNWRAP > 5. TCP send the 6 bytes > 6. Unwrap 6 and 907, then NEED_WRAP > 7. Generate 58 then FINISHED > 8 TCP send the 58 bytes. > > You can see that the client issues 3 TCP sends. > > With what I am suggesting, the client would only issue 2 TCP sends, > which seems more in line with the efforts in TLS 1.3 to be more > efficient. > > It would just be a matter of *generating* those 6 bytes a bit later, > *after* having fully unwrapped the ServerHello. > It's a good idea! >> We may consider a option to turn off the middlebox compatibility mode if >> it helps Jetty. > > No need to. > >> But the implementation code and the application should >> be ready to accept the fact that third party's implementation may be >> implemented in middlebox compatibility mode, and the change_cipher_spec >> record may still come in. > > See above, it's not about processing the dummy change_cipher_spec, > it's just about generating it a little later. > >> After #7 (FINISHED), if the client only send application data, but never >> call read again, it still works, right? The application don't have to >> read something, I think. > > Sure, it just can't take advantage of session resumption though. > The client never knows that there are post-handshake messages to read > because SSLEgine did not tell. > SSLEngine just said FINISHED and NOT_HANDSHAKING. > > However, I see your point. Handshake messages could come at any time, > just that this one seems more part of the initial handshake, > especially if it's about session resumption. > Yes. Applications using SSLEngine may want to monitor the network incoming, and call unwrap() when there is something comes. Otherwise, if the SSLEngine client does not try to read any more, there is no chance to get the post-handshake message. I know some application might never read again after the full handshake, but it may not be able to work for some user cases (session resumption, etc), even in the TLS 1.2 context. As SSLEngine knows nothing about the underlying transportation, there is not much it can do here. >> in #10, you said, "Client MUST unwrap ...". Do you mean that the client >> cannot send application data without read/unwrap something? > > It can send data, but won't be good to leave unprocessed bytes around. > The application would not know that there is stuff to read from the > network and to process as post-handshake messages. > It may never read from the network again. > See above. Thank you very much, Simone. I find at least two improvements we can take. It's really good! Regards, Xuelei >> Half-close means that the server may not send the close_notify when it >> receive the client close_notify. It's a very tricky policy. The client >> close_notify only means the client want to close its writing side. The >> server may not send the close_notify if it doesn't want to close. If we >> have the client goes into NEED_UNWRAP, there is a potential dead waiting. > > Good point. > > Thanks! > From sean.mullan at oracle.com Fri Jul 13 13:56:33 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jul 2018 09:56:33 -0400 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> Message-ID: <93676c63-04c2-c614-3b35-014107c74531@oracle.com> On 7/12/18 10:23 PM, Weijun Wang wrote: > > >> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >> >> Hi Max, >> >> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. > > Sure. > >> >> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". > > > OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. > > Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? > > "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. > >> >> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. > > I assume other getParameters() had not added it is because it happened they can return one. > > While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. > > For example, @throws SecurityException for File/Files operations. Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. --Sean > > Thanks > Max > >> >> Thanks, >> Valerie >> >> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>> Hi Valerie >>> >>> About "it *may* return", do you mean it could also return null? My understanding is no. >>> >>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>> >>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>> >>> Thanks >>> Max >>> >>> >>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>> >>>> Hi Brad, >>>> >>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>> Otherwise, JCK team expects a parameter object or null being returned. >>>> I filed a CSR to track the javadoc clarification. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>> >>>> Thanks, >>>> Valerie >>>> >>>> >>>> >> > From adam.petcher at oracle.com Fri Jul 13 15:08:18 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 13 Jul 2018 11:08:18 -0400 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> Message-ID: <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> Here's a new Webrev that includes this change: http://cr.openjdk.java.net/~apetcher/8206929/webrev.01/ On 7/12/2018 1:02 PM, Xuelei Fan wrote: > Set it in PostHandshakeContext should be fine as the session should > have been negotiated. > > Thanks, > Xuelei > > On 7/12/2018 9:57 AM, Adam Petcher wrote: >> This value needs to be set when we create a PostHandshakeContext from >> a TransportContext. This only happens after the handshake is >> complete, so we should always have a session (right?). >> >> It may be better to set localSupportedSignAlgs in the constructor of >> PostHandshakeContext instead of where it is now. Would that address >> your concern? >> >> >> On 7/12/2018 12:45 PM, Xuelei Fan wrote: >>> A quick question about the update in HandshakeContext.java. >>> >>> +?? this.localSupportedSignAlgs = new ArrayList( >>> + conContext.conSession.getLocalSupportedSignatureSchemes()); >>> >>> Why set the value here?? The 'null' value of localSupportedSignAlgs >>> has a special meaning that it has not been set.? A few places depend >>> on this special value.? The above update may set it to empty if the >>> session has not been established, and then prevent the proper >>> setting of the value of it later. >>> >>> Xuelei >>> >>> On 7/12/2018 8:50 AM, Adam Petcher wrote: >>>> This change adds some checks for session resumption in TLS 1.3 to >>>> ensure that the resumed session is compatible with what is >>>> requested. Specifically, I'm adding checks for protocol version, >>>> cipher suite, client authentication, and signature schemes. There >>>> are also some minor whitespace formatting changes in >>>> PreSharedKeyExtension.java. >>>> >>>> This is a JDK 11 change, so please review soon. >>>> >>>> Webrev: http://cr.openjdk.java.net/~apetcher/8206929/webrev.00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206929 >>>> >> From xuelei.fan at oracle.com Fri Jul 13 15:34:02 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 13 Jul 2018 08:34:02 -0700 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> Message-ID: <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> PreSharedKeyExtension.java -------------------------- The local supported signature algorithms are checked in the canRejoin() method. Should the peer supported signature algorithms be checked as well? Thanks, Xuelei On 7/13/2018 8:08 AM, Adam Petcher wrote: > Here's a new Webrev that includes this change: > http://cr.openjdk.java.net/~apetcher/8206929/webrev.01/ > > > On 7/12/2018 1:02 PM, Xuelei Fan wrote: >> Set it in PostHandshakeContext should be fine as the session should >> have been negotiated. >> >> Thanks, >> Xuelei >> >> On 7/12/2018 9:57 AM, Adam Petcher wrote: >>> This value needs to be set when we create a PostHandshakeContext from >>> a TransportContext. This only happens after the handshake is >>> complete, so we should always have a session (right?). >>> >>> It may be better to set localSupportedSignAlgs in the constructor of >>> PostHandshakeContext instead of where it is now. Would that address >>> your concern? >>> >>> >>> On 7/12/2018 12:45 PM, Xuelei Fan wrote: >>>> A quick question about the update in HandshakeContext.java. >>>> >>>> +?? this.localSupportedSignAlgs = new ArrayList( >>>> + conContext.conSession.getLocalSupportedSignatureSchemes()); >>>> >>>> Why set the value here?? The 'null' value of localSupportedSignAlgs >>>> has a special meaning that it has not been set.? A few places depend >>>> on this special value.? The above update may set it to empty if the >>>> session has not been established, and then prevent the proper >>>> setting of the value of it later. >>>> >>>> Xuelei >>>> >>>> On 7/12/2018 8:50 AM, Adam Petcher wrote: >>>>> This change adds some checks for session resumption in TLS 1.3 to >>>>> ensure that the resumed session is compatible with what is >>>>> requested. Specifically, I'm adding checks for protocol version, >>>>> cipher suite, client authentication, and signature schemes. There >>>>> are also some minor whitespace formatting changes in >>>>> PreSharedKeyExtension.java. >>>>> >>>>> This is a JDK 11 change, so please review soon. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8206929/webrev.00/ >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206929 >>>>> >>> > From adam.petcher at oracle.com Fri Jul 13 16:10:40 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 13 Jul 2018 12:10:40 -0400 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> Message-ID: On 7/13/2018 11:34 AM, Xuelei Fan wrote: > PreSharedKeyExtension.java > -------------------------- > The local supported signature algorithms are checked in the > canRejoin() method.? Should the peer supported signature algorithms be > checked as well? I don't think so. When the peer creates its PreSharedKeyExtension, it should only offer sessions (i.e. PSK identities) that it is willing to resume. This includes checking for its supported signature algorithms, or any checks that are required by its policy. If the server gets a PSK identity from the client, then server should use that PSK to resume a session as long as it is acceptable according to the server's policy. Trying to figure out the peer's policy and enforce it is error prone and adds unnecessary complexity. Though maybe I'm missing some other motivation to add this check. From simone.bordet at gmail.com Fri Jul 13 16:19:53 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Fri, 13 Jul 2018 18:19:53 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: <7998962c-9060-b1cd-8116-17da18981796@oracle.com> References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> Message-ID: Hi, On Fri, Jul 13, 2018 at 3:45 PM Xuelei Fan wrote: > Thank you very much, Simone. I find at least two improvements we can > take. It's really good! Great! Let know when they land in a 11+X release and we'll try them out. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Fri Jul 13 17:35:18 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 13 Jul 2018 10:35:18 -0700 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> Message-ID: <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> I think we need to check more aspects, for both the session resumption producer and consumer: 1. the local is able to resume the session. 2. the peer is able to resume the session. 3. the change of the security parameters does not impact the resumption. So, for the protocol version checking in server side: 1. the client requested to use the negotiated version. 2. the server still supports the negotiated version. I think #2 is get checked in line 406-414 block. Did we check #1 in somewhere else? For the cipher suite checking in server side: 1. the client requested to use the negotiate cipher suite. 2. the server still supports the negotiated cipher suite. I think #2 is get checked in line 445-453 block. Did we check #1 in somewhere else? For the signature algorithms checking in server side: 1. the client requested to use the algorithms used in full handshake 2. the server still supports the algorithms used in full handshake The algorithms used in full handshake is one element or a subset of the local and peer supported algorithms. We may not cache the used algorithms in the session. But it is acceptable to me to use defensive policy that we don't allow session resumption if the supported algorithms get changed (as you did in the webrev to use Collection.containsAll() line 435). As reminded me that we may also want to check for both the signature_algorithms and signature_algorithms algorithms. I think #2 is get checked in line 431-442 block. Did we check #1 in somewhere else? On 7/13/2018 9:10 AM, Adam Petcher wrote: > On 7/13/2018 11:34 AM, Xuelei Fan wrote: > >> PreSharedKeyExtension.java >> -------------------------- >> The local supported signature algorithms are checked in the >> canRejoin() method.? Should the peer supported signature algorithms be >> checked as well? > > I don't think so. When the peer creates its PreSharedKeyExtension, it > should only offer sessions (i.e. PSK identities) that it is willing to > resume. This includes checking for its supported signature algorithms, > or any checks that are required by its policy. I see your point. But the peer is not trustworthy so that we normally validate the input to make sure the peer is doing the right thing. Thanks, Xuelei > If the server gets a PSK > identity from the client, then server should use that PSK to resume a > session as long as it is acceptable according to the server's policy. > Trying to figure out the peer's policy and enforce it is error prone and > adds unnecessary complexity. > > Though maybe I'm missing some other motivation to add this check. From valerie.peng at oracle.com Fri Jul 13 18:05:10 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 13 Jul 2018 11:05:10 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <93676c63-04c2-c614-3b35-014107c74531@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> Message-ID: <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> Hmm, I like the idea of expanding null to cover both cases. I will explore it more and see. Thanks for the feedback, Valerie On 7/13/2018 6:56 AM, Sean Mullan wrote: > On 7/12/18 10:23 PM, Weijun Wang wrote: >> >> >>> On Jul 13, 2018, at 10:01 AM, Valerie Peng >>> wrote: >>> >>> Hi Max, >>> >>> The javadoc is for Signature.getParameters(), so null can be >>> returned for signature algorithms which do not use parameters, e.g. >>> SHA256withDSA. As Signature class covers all signature algorithms, I >>> am not sure about mentioning specific algorithm names as it may be >>> lengthy and even misleading unless we list out all applicable >>> algorithms. >> >> Sure. >> >>> >>> The part of "default and randomly generated" is inherited from >>> existing javadoc. I think "default" in the aforementioned sentence >>> means "hardcoded values". For example, something like salt length >>> will likely have a fixed default value. Since we have no control >>> over 3rd party providers, I think we may have to keep this for >>> backward compatibility reason. For RSASSA-PSS sig algorithm, it >>> errors out if the required parameter is not given. Thus, I added the >>> sentence "If there are no provider-specific default values, the >>> underlying signature implementation may also fail". >> >> >> OK, now I understand "a combination of default and randomly >> generated" means some part of the parameter is hardcoded and some is >> random. Anyway, let's keep it unchanged. >> >> Then, how about simply "If there are no provider-specific values" >> which covers both hardcoded and random values? >> >> "the underlying signature implementation may also fail" is still not >> clear to me. If I had not read the CSR I would thought an exception >> will be thrown when update/sign is called. >> >>> >>> As for @throws, I debated about it. The main reason for not adding >>> one is consistency. Many (or should I say most) security classes do >>> not have @throws for ProviderException. If we were to add @throws >>> ProviderException here, we should do it across the board. Besides, >>> it is recommended to NOT document runtime exceptions which callers >>> are not prepared to handle. >> >> I assume other getParameters() had not added it is because it >> happened they can return one. >> >> While people does not catch runtime exceptions but my understanding >> is that if you mentioned "fail" in the spec maybe it's better to add >> a @throws for it. >> >> For example, @throws SecurityException for File/Files operations. > > Thinking more about this, I would be more inclined to recommend that > you change the meaning of null as the return value to cover both cases: > > @return the parameters used with this signature, or null if this > signature does not use any parameters or does not support default or > randomly generated parameter values > > I don't think it is critical to make a distinction between these 2 > cases, because if the programmer doesn't initialize it with parameters > it will get a SignatureException anyway when it tries to call sign or > verify. > > It's not perfect, but probably the best you can do working within the > constraints of that API and minimizing compatibility risk. > > --Sean > >> >> Thanks >> Max >> >>> >>> Thanks, >>> Valerie >>> >>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>> Hi Valerie >>>> >>>> About "it *may* return", do you mean it could also return null? My >>>> understanding is no. >>>> >>>> Is it better to clarify when the implementation "may also fail"? >>>> From the CSR, it's this method. Can you add a @throws spec to this >>>> method then? >>>> >>>> Also, I am a little confused by "default and randomly generated". >>>> Does this actually mean "default (might be randomly generated)"? >>>> The "it may" sentence mentions "default and randomly generated" but >>>> the "if there" only says "default", which sounds like the the >>>> "randomly generated" case could be different. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng >>>>> wrote: >>>>> >>>>> Hi Brad, >>>>> >>>>> Would you have time to review the fix for JDK-8206171: >>>>> Signature#getParameters for RSASSA-PSS throws ProviderException >>>>> when not initialized? >>>>> No source code changes, but just updating javadoc to mention the >>>>> possible failure case. >>>>> Otherwise, JCK team expects a parameter object or null being >>>>> returned. >>>>> I filed a CSR to track the javadoc clarification. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> >>>>> >>> >> From adam.petcher at oracle.com Fri Jul 13 19:13:17 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 13 Jul 2018 15:13:17 -0400 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> Message-ID: <3d9cc98e-4c6c-9802-bab4-4ea94cda9907@oracle.com> On 7/13/2018 1:35 PM, Xuelei Fan wrote: > I think we need to check more aspects, for both the session resumption > producer and consumer: > 1. the local is able to resume the session. > 2. the peer is able to resume the session. > 3. the change of the security parameters does not impact the resumption. 1 and 3 I agree with, and I believe are pretty well covered (after this change), but I'm still not convinced that the implementation should do any checking on behalf of the peer. This includes checking the peer supported signature algorithms. Maybe this is a good idea, but I think it is not in scope of this ticket, and it should be discussed separately. If you want to pursue this, feel free to open another ticket for it. > > So, for the protocol version checking in server side: > 1. the client requested to use the negotiated version. > 2. the server still supports the negotiated version. > > I think #2 is get checked in line 406-414 block. Yes. > Did we check #1 in somewhere else? A lot of the checks for the client side uses existing code, and is shared between TLS 1.3 and earlier versions. The way it works is that the shared code will decide which session to resume in ClientHello. At this point, a lot of things are checked, including the protocol version of the session. Only if this code decides that a session should be resumed, then the code for TLS 1.3+ in PreSharedKeyExtension will perform the additional checks that are specific to TLS 1.3 and then produce the extension. Specifically, the protocol version is checked in ClientHello.java near line 458 (in existing code). > > For the cipher suite checking in server side: > 1. the client requested to use the negotiate cipher suite. > 2. the server still supports the negotiated cipher suite. > > I think #2 is get checked in line 445-453 block. Yes. > Did we check #1 in somewhere else? ClientHello.java near line 445 (in existing code). > > > For the signature algorithms checking in server side: > 1. the client requested to use the algorithms used in full handshake > 2. the server still supports the algorithms used in full handshake > > The algorithms used in full handshake is one element or a subset of > the local and peer supported algorithms.?? We may not cache the used > algorithms in the session.? But it is acceptable to me to use > defensive policy that we don't allow session resumption if the > supported algorithms get changed (as you did in the webrev to use > Collection.containsAll() line 435). We do cache the certificate chain. If we wanted to, we could examine the chain and make sure all of the signature algorithms in the chain are still supported. I didn't think this was worth the effort, though. > > As reminded me that we may also want to check for both the > signature_algorithms and signature_algorithms algorithms. Did you mean signature_algorithms and signature_algorithms_cert? I think that is handled correctly now, because the set of (local) supported signature algorithms for certificates and handshake messages will always be the same (right?). We only have one field for this in HandshakeContext: localSupportedSignAlgs. The way it is used in the code, this field is used for both handshake messages and certificates. > > I think #2 is get checked in line 431-442 block. Yes. > Did we check #1 in somewhere else? Because this is specific to TLS 1.3+, I put it in the CHPreSharedKeyProducer. That is in PreSharedKeyExtension.java, near line 610 (in the new code in the Webrev). > > On 7/13/2018 9:10 AM, Adam Petcher wrote: >> On 7/13/2018 11:34 AM, Xuelei Fan wrote: >> >>> PreSharedKeyExtension.java >>> -------------------------- >>> The local supported signature algorithms are checked in the >>> canRejoin() method.? Should the peer supported signature algorithms >>> be checked as well? >> >> I don't think so. When the peer creates its PreSharedKeyExtension, it >> should only offer sessions (i.e. PSK identities) that it is willing >> to resume. This includes checking for its supported signature >> algorithms, or any checks that are required by its policy. > I see your point.? But the peer is not trustworthy so that we normally > validate the input to make sure the peer is doing the right thing. > > Thanks, > Xuelei > >> If the server gets a PSK identity from the client, then server should >> use that PSK to resume a session as long as it is acceptable >> according to the server's policy. Trying to figure out the peer's >> policy and enforce it is error prone and adds unnecessary complexity. >> >> Though maybe I'm missing some other motivation to add this check. From xuelei.fan at oracle.com Fri Jul 13 20:55:56 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 13 Jul 2018 13:55:56 -0700 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: <3d9cc98e-4c6c-9802-bab4-4ea94cda9907@oracle.com> References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> <3d9cc98e-4c6c-9802-bab4-4ea94cda9907@oracle.com> Message-ID: On 7/13/2018 12:13 PM, Adam Petcher wrote: > On 7/13/2018 1:35 PM, Xuelei Fan wrote: > >> I think we need to check more aspects, for both the session resumption >> producer and consumer: >> 1. the local is able to resume the session. >> 2. the peer is able to resume the session. >> 3. the change of the security parameters does not impact the resumption. > > 1 and 3 I agree with, and I believe are pretty well covered (after this > change), but I'm still not convinced that the implementation should do > any checking on behalf of the peer. It is not necessary to be on behalf of the peer. The local can check if the peer request something correctly. We normally call it input validation. > This includes checking the peer > supported signature algorithms. Maybe this is a good idea, but I think > it is not in scope of this ticket, and it should be discussed > separately. If you want to pursue this, feel free to open another ticket > for it. > I would treat it as a part of the bug. I'm fine if you just want to fix half of it. I need a confirmation. Please let me know if you want another half be addressed in a new bug. >> >> So, for the protocol version checking in server side: >> 1. the client requested to use the negotiated version. >> 2. the server still supports the negotiated version. >> >> I think #2 is get checked in line 406-414 block. > Yes. > >> Did we check #1 in somewhere else? > > A lot of the checks for the client side uses existing code, and is > shared between TLS 1.3 and earlier versions. The way it works is that > the shared code will decide which session to resume in ClientHello. At > this point, a lot of things are checked, including the protocol version > of the session. Only if this code decides that a session should be > resumed, then the code for TLS 1.3+ in PreSharedKeyExtension will > perform the additional checks that are specific to TLS 1.3 and then > produce the extension. > > Specifically, the protocol version is checked in ClientHello.java near > line 458 (in existing code). > I meant to ask whether server side validate the client input. See what we did for TLS v1.2 in line 973 of ClientHello.java. >> >> For the cipher suite checking in server side: >> 1. the client requested to use the negotiate cipher suite. >> 2. the server still supports the negotiated cipher suite. >> >> I think #2 is get checked in line 445-453 block. > > Yes. > >> Did we check #1 in somewhere else? > > ClientHello.java near line 445 (in existing code). > I meant to ask whether server side validate the client input. See what we did for TLS v1.2 in line 1003. >> >> >> For the signature algorithms checking in server side: >> 1. the client requested to use the algorithms used in full handshake >> 2. the server still supports the algorithms used in full handshake >> >> The algorithms used in full handshake is one element or a subset of >> the local and peer supported algorithms.?? We may not cache the used >> algorithms in the session.? But it is acceptable to me to use >> defensive policy that we don't allow session resumption if the >> supported algorithms get changed (as you did in the webrev to use >> Collection.containsAll() line 435). > > We do cache the certificate chain. If we wanted to, we could examine the > chain and make sure all of the signature algorithms in the chain are > still supported. I didn't think this was worth the effort, though. > I'm fine to use the defensive policy. I don't purchase for a perfect check. >> >> As reminded me that we may also want to check for both the >> signature_algorithms and signature_algorithms algorithms. > > Did you mean signature_algorithms and signature_algorithms_cert? I think > that is handled correctly now, because the set of (local) supported > signature algorithms for certificates and handshake messages will always > be the same (right?). Right, the local algorithms checking should be sufficient. > We only have one field for this in > HandshakeContext: localSupportedSignAlgs. The way it is used in the > code, this field is used for both handshake messages and certificates. > >> >> I think #2 is get checked in line 431-442 block. > It's for local algorithms. We should valid the peer input as well. > Yes. > >> Did we check #1 in somewhere else? > > Because this is specific to TLS 1.3+, I put it in the > CHPreSharedKeyProducer. That is in PreSharedKeyExtension.java, near line > 610 (in the new code in the Webrev). > Yes, it is a good check the generation. We also need to valid the peer input as well, in the consumer. In the producer, it is call local supported signature algorithms; in the consumer, the corresponding one is peer support signature algorithms. Peer support signature algorithms should be validated for session resumption, I think. Thanks, Xuelei >> >> On 7/13/2018 9:10 AM, Adam Petcher wrote: >>> On 7/13/2018 11:34 AM, Xuelei Fan wrote: >>> >>>> PreSharedKeyExtension.java >>>> -------------------------- >>>> The local supported signature algorithms are checked in the >>>> canRejoin() method.? Should the peer supported signature algorithms >>>> be checked as well? >>> >>> I don't think so. When the peer creates its PreSharedKeyExtension, it >>> should only offer sessions (i.e. PSK identities) that it is willing >>> to resume. This includes checking for its supported signature >>> algorithms, or any checks that are required by its policy. >> I see your point.? But the peer is not trustworthy so that we normally >> validate the input to make sure the peer is doing the right thing. >> >> Thanks, >> Xuelei >> >>> If the server gets a PSK identity from the client, then server should >>> use that PSK to resume a session as long as it is acceptable >>> according to the server's policy. Trying to figure out the peer's >>> policy and enforce it is error prone and adds unnecessary complexity. >>> >>> Though maybe I'm missing some other motivation to add this check. > From valerie.peng at oracle.com Fri Jul 13 21:08:37 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 13 Jul 2018 14:08:37 -0700 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Message-ID: Thanks for updating the webrev, I will take a look. Valerie On 7/10/2018 10:18 AM, Martin Balao wrote: > Hi, > > Webrev 04 for JDK-8029661 is ready: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.04.zip > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.04/ > > > New: > > ?* Rebased to latest JDK revision (after TLS 1.3 merge) > ? * Rev 1acfd2f56d72 > ?* ProtocolVersion dependencies removed (raw TLS protocol version > numbers are now used) > ?* Code style improvements (tabs, trailing whitespaces, max lines > length, etc.) > > Thanks, > Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Sat Jul 14 01:30:14 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 13 Jul 2018 21:30:14 -0400 Subject: EC weirdness Message-ID: Hi - Every so often I run into some rather strange things in the way the Sun EC classes were built.? Most recently, I was trying to use the SunEC provider to do a PACE like protocol.? Basically, the idea was to be able to generate public key points on the P-256 curve, but with a different base point G (knowledge of G' or having a public key generated from G' would allow you to do a valid ECDH operation, keys with disjoint points would not). I was able to generate a normal key pair using ECGenParameterSpec with a name, so I grabbed the ECParameterSpec from the public key, made a copy of most of the stuff (curve, cofactor), but substituted the public point W from the key pair I'd just generated, and passed that in as G to the new parameter spec.? I tried to initialize the KPG with my *almost* P-256 spec, and it failed with "unsupported curve". Looking into the code and tracing through sun.crypto.ec.ECKeyPairGenerator to the native code, I'm once again surprised that all of the curves are hard coded into the C native code, rather than being passed in as data from the Java code. Is there a good security reason for hard coding the curves at the C level that I'm missing? This comes under the heading of unexpected behavior rather than a bug per se I think.?? Although - I'd *really* like to be able to pass a valid ECParameterSpec in to the generation process and get whatever keys are appropriate for that curve and base point. Later, Mike From rajan.halade at oracle.com Mon Jul 16 15:33:54 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 16 Jul 2018 08:33:54 -0700 Subject: RFR: 8207321: Merge error with 8199779 Message-ID: Please review this fix to merge correct cacerts file. Merge error caused by forward port to JDK 12 with 8207311. Webrev: http://cr.openjdk.java.net/~rhalade/8207321/webrev.00/ Thanks, Rajan From sean.mullan at oracle.com Mon Jul 16 15:53:37 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 Jul 2018 11:53:37 -0400 Subject: RFR: 8207321: Merge error with 8199779 In-Reply-To: References: Message-ID: <91cbef06-7af8-42a6-b913-5846b58ab92c@oracle.com> Looks good. Bug needs a noreg label. --Sean On 7/16/18 11:33 AM, Rajan Halade wrote: > Please review this fix to merge correct cacerts file. Merge error caused > by forward port to JDK 12 with 8207311. > > Webrev: http://cr.openjdk.java.net/~rhalade/8207321/webrev.00/ > > Thanks, > Rajan From adam.petcher at oracle.com Mon Jul 16 17:38:54 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 16 Jul 2018 13:38:54 -0400 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> <3d9cc98e-4c6c-9802-bab4-4ea94cda9907@oracle.com> Message-ID: New webrev: http://cr.openjdk.java.net/~apetcher/8206929/webrev.02/ On 7/13/2018 4:55 PM, Xuelei Fan wrote: > On 7/13/2018 12:13 PM, Adam Petcher wrote: > >> This includes checking the peer supported signature algorithms. Maybe >> this is a good idea, but I think it is not in scope of this ticket, >> and it should be discussed separately. If you want to pursue this, >> feel free to open another ticket for it. >> > I would treat it as a part of the bug.? I'm fine if you just want to > fix half of it.? I need a confirmation.? Please let me know if you > want another half be addressed in a new bug. Confirmed. I'm only adding checks to ensure that sessions are acceptable according to local constraints, which may be influenced by information in messages. If you think additional validation is needed, please create another ticket. I believe I have addressed the issues with protocol version and cipher suite (because they are related to local constraints), and the only remaining issue is the check for peer-supported signature schemes. > I meant to ask whether server side validate the client input.? See > what we did for TLS v1.2 in line 973 of ClientHello.java. Sorry. I misunderstood what you asked. I think we should do the same thing, and this is a minor bug in the Webrev. At the point where the client's PSK extension is processed, the protocol version has already been negotiated. So the server can check the session version against the negotiated version. The latest Webrev has this change. > I meant to ask whether server side validate the client input.? See > what we did for TLS v1.2 in line 1003. I misunderstood this question, too. I agree that we should add this check to make sure the cipher suite in the session can be negotiated. This change is in the updated Webrev. Note that the relationship between sessions/PSKs and cipher suites is different in TLS 1.2 vs 1.3. In TLS 1.3, the cipher suite doesn't need to match---only the hash algorithm needs to match. We can make our implementation more permissive in the future, but for now, checking cipher suites is simpler. From xuelei.fan at oracle.com Mon Jul 16 19:04:07 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Jul 2018 12:04:07 -0700 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> <3d9cc98e-4c6c-9802-bab4-4ea94cda9907@oracle.com> Message-ID: <68363bfe-0f70-ef9f-065f-a1413d697f64@oracle.com> On 7/16/2018 10:38 AM, Adam Petcher wrote: > Note that the relationship between sessions/PSKs and cipher suites is > different in TLS 1.2 vs 1.3. In TLS 1.3, the cipher suite doesn't need > to match---only the hash algorithm needs to match. I did not get your point. Would you mind describe it more? Xuelei > We can make our > implementation more permissive in the future, but for now, checking > cipher suites is simpler. From adam.petcher at oracle.com Mon Jul 16 19:52:47 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 16 Jul 2018 15:52:47 -0400 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: <68363bfe-0f70-ef9f-065f-a1413d697f64@oracle.com> References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> <3d9cc98e-4c6c-9802-bab4-4ea94cda9907@oracle.com> <68363bfe-0f70-ef9f-065f-a1413d697f64@oracle.com> Message-ID: <18e0547a-8e7b-3806-e18c-27dff6bad2df@oracle.com> On 7/16/2018 3:04 PM, Xuelei Fan wrote: > On 7/16/2018 10:38 AM, Adam Petcher wrote: >> Note that the relationship between sessions/PSKs and cipher suites is >> different in TLS 1.2 vs 1.3. In TLS 1.3, the cipher suite doesn't >> need to match---only the hash algorithm needs to match. > I did not get your point.? Would you mind describe it more? Section 4.2.11 of the I-D: Each PSK is associated with a single Hash algorithm. For PSKs established via the ticket mechanism (Section 4.6.1 ), this is the KDF Hash algorithm on the connection where the ticket was established. For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is defined. The server MUST ensure that it selects a compatible PSK (if any) and cipher suite. and Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected a cipher suite indicating a Hash associated with the PSK and that a server "key_share" extension is present if required by the ClientHello "psk_key_exchange_modes". Section 4.6.1: Any ticket MUST only be resumed with a cipher suite that has the same KDF hash algorithm as that used to establish the original connection. So the ticket/PSK only has an associated hash algorithm, and the connection may use the PSK with any cipher suite as long as the hash algorithm is the same (unless I am missing some constraints in the RFC). As our implementation is now, the PSK may only be used if it has the same cipher suite as the session that created it. If the client/server no longer supports the cipher suite of the session that created the PSK, but it supports some other cipher suite with the same hash, then the session will not be resumed, even though the standard allows it to be resumed using another cipher suite. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Mon Jul 16 20:42:29 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 16 Jul 2018 16:42:29 -0400 Subject: EC weirdness In-Reply-To: References: Message-ID: <98f90517-33a5-5c62-3c2b-89c75967874e@oracle.com> I think the reason for the hard-coded curves is largely historical, and I don't know of a security-related reason for it (other than the prevention of insecure parameters). Though it has the additional benefit that it simplifies the interface a lot, because the implementation for a curve is not completely determined by the domain parameters. The implementation may also need to know which optimized finite field implementation, precomputed tables, etc to use. Looking up all of these things at once can be a lot simpler than trying to specify them over an interface. I'm trying to figure out if your problem motivates support for arbitrary base points, or if there is another way to get what you want. Is the base point a secret in your scheme? Either way, can you implement your scheme using KeyAgreement (e.g. using the "base point" as the public key and a random integer as the private key)? What if ECDH KeyAgreement supported three-party Diffie-Hellman, or you extract a point from generateSecret()? Would that help? On 7/13/2018 9:30 PM, Michael StJohns wrote: > Hi - > > Every so often I run into some rather strange things in the way the > Sun EC classes were built.? Most recently, I was trying to use the > SunEC provider to do a PACE like protocol.? Basically, the idea was to > be able to generate public key points on the P-256 curve, but with a > different base point G (knowledge of G' or having a public key > generated from G' would allow you to do a valid ECDH operation, keys > with disjoint points would not). > > I was able to generate a normal key pair using ECGenParameterSpec with > a name, so I grabbed the ECParameterSpec from the public key, made a > copy of most of the stuff (curve, cofactor), but substituted the > public point W from the key pair I'd just generated, and passed that > in as G to the new parameter spec.? I tried to initialize the KPG with > my *almost* P-256 spec, and it failed with "unsupported curve". > > Looking into the code and tracing through > sun.crypto.ec.ECKeyPairGenerator to the native code, I'm once again > surprised that all of the curves are hard coded into the C native > code, rather than being passed in as data from the Java code. > > Is there a good security reason for hard coding the curves at the C > level that I'm missing? > > This comes under the heading of unexpected behavior rather than a bug > per se I think.?? Although - I'd *really* like to be able to pass a > valid ECParameterSpec in to the generation process and get whatever > keys are appropriate for that curve and base point. > > Later, Mike > > > > From xuelei.fan at oracle.com Mon Jul 16 21:07:24 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Jul 2018 14:07:24 -0700 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: <18e0547a-8e7b-3806-e18c-27dff6bad2df@oracle.com> References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> <3d9cc98e-4c6c-9802-bab4-4ea94cda9907@oracle.com> <68363bfe-0f70-ef9f-065f-a1413d697f64@oracle.com> <18e0547a-8e7b-3806-e18c-27dff6bad2df@oracle.com> Message-ID: <20022caa-507d-5786-5d12-52908515ce01@oracle.com> You might not notice that traffic secrets depend on the cipher suite. Xuelei On 7/16/2018 12:52 PM, Adam Petcher wrote: > On 7/16/2018 3:04 PM, Xuelei Fan wrote: > >> On 7/16/2018 10:38 AM, Adam Petcher wrote: >>> Note that the relationship between sessions/PSKs and cipher suites is >>> different in TLS 1.2 vs 1.3. In TLS 1.3, the cipher suite doesn't >>> need to match---only the hash algorithm needs to match. >> I did not get your point.? Would you mind describe it more? > Section 4.2.11 of the I-D: > > Each PSK is associated with a single Hash algorithm. For PSKs > established via the ticket mechanism (Section 4.6.1 > ), this is the KDF > Hash algorithm on the connection where the ticket was established. > For externally established PSKs, the Hash algorithm MUST be set when > the PSK is established, or default to SHA-256 if no such algorithm is > defined. The server MUST ensure that it selects a compatible PSK (if > any) and cipher suite. > > and > > Clients MUST verify that the server's selected_identity is within the > range supplied by the client, that the server selected a cipher suite > indicating a Hash associated with the PSK and that a server > "key_share" extension is present if required by the ClientHello > "psk_key_exchange_modes". > > Section 4.6.1: > > Any ticket MUST only be resumed with a cipher suite that has the same > KDF hash algorithm as that used to establish the original connection. > > > So the ticket/PSK only has an associated hash algorithm, and the > connection may use the PSK with any cipher suite as long as the hash > algorithm is the same (unless I am missing some constraints in the RFC). > As our implementation is now, the PSK may only be used if it has the > same cipher suite as the session that created it. If the client/server > no longer supports the cipher suite of the session that created the PSK, > but it supports some other cipher suite with the same hash, then the > session will not be resumed, even though the standard allows it to be > resumed using another cipher suite. From valerie.peng at oracle.com Mon Jul 16 22:16:10 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 16 Jul 2018 15:16:10 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> Message-ID: <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 Thanks, Valerie On 7/13/2018 11:05 AM, Valerie Peng wrote: > > Hmm, I like the idea of expanding null to cover both cases. > I will explore it more and see. > Thanks for the feedback, > Valerie > > On 7/13/2018 6:56 AM, Sean Mullan wrote: >> On 7/12/18 10:23 PM, Weijun Wang wrote: >>> >>> >>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng >>>> wrote: >>>> >>>> Hi Max, >>>> >>>> The javadoc is for Signature.getParameters(), so null can be >>>> returned for signature algorithms which do not use parameters, e.g. >>>> SHA256withDSA. As Signature class covers all signature algorithms, >>>> I am not sure about mentioning specific algorithm names as it may >>>> be lengthy and even misleading unless we list out all applicable >>>> algorithms. >>> >>> Sure. >>> >>>> >>>> The part of "default and randomly generated" is inherited from >>>> existing javadoc. I think "default" in the aforementioned sentence >>>> means "hardcoded values". For example, something like salt length >>>> will likely have a fixed default value. Since we have no control >>>> over 3rd party providers, I think we may have to keep this for >>>> backward compatibility reason. For RSASSA-PSS sig algorithm, it >>>> errors out if the required parameter is not given. Thus, I added >>>> the sentence "If there are no provider-specific default values, the >>>> underlying signature implementation may also fail". >>> >>> >>> OK, now I understand "a combination of default and randomly >>> generated" means some part of the parameter is hardcoded and some is >>> random. Anyway, let's keep it unchanged. >>> >>> Then, how about simply "If there are no provider-specific values" >>> which covers both hardcoded and random values? >>> >>> "the underlying signature implementation may also fail" is still not >>> clear to me. If I had not read the CSR I would thought an exception >>> will be thrown when update/sign is called. >>> >>>> >>>> As for @throws, I debated about it. The main reason for not adding >>>> one is consistency. Many (or should I say most) security classes do >>>> not have @throws for ProviderException. If we were to add @throws >>>> ProviderException here, we should do it across the board. Besides, >>>> it is recommended to NOT document runtime exceptions which callers >>>> are not prepared to handle. >>> >>> I assume other getParameters() had not added it is because it >>> happened they can return one. >>> >>> While people does not catch runtime exceptions but my understanding >>> is that if you mentioned "fail" in the spec maybe it's better to add >>> a @throws for it. >>> >>> For example, @throws SecurityException for File/Files operations. >> >> Thinking more about this, I would be more inclined to recommend that >> you change the meaning of null as the return value to cover both cases: >> >> @return the parameters used with this signature, or null if this >> signature does not use any parameters or does not support default or >> randomly generated parameter values >> >> I don't think it is critical to make a distinction between these 2 >> cases, because if the programmer doesn't initialize it with >> parameters it will get a SignatureException anyway when it tries to >> call sign or verify. >> >> It's not perfect, but probably the best you can do working within the >> constraints of that API and minimizing compatibility risk. >> >> --Sean >> >>> >>> Thanks >>> Max >>> >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>> Hi Valerie >>>>> >>>>> About "it *may* return", do you mean it could also return null? My >>>>> understanding is no. >>>>> >>>>> Is it better to clarify when the implementation "may also fail"? >>>>> From the CSR, it's this method. Can you add a @throws spec to this >>>>> method then? >>>>> >>>>> Also, I am a little confused by "default and randomly generated". >>>>> Does this actually mean "default (might be randomly generated)"? >>>>> The "it may" sentence mentions "default and randomly generated" >>>>> but the "if there" only says "default", which sounds like the the >>>>> "randomly generated" case could be different. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng >>>>>> wrote: >>>>>> >>>>>> Hi Brad, >>>>>> >>>>>> Would you have time to review the fix for JDK-8206171: >>>>>> Signature#getParameters for RSASSA-PSS throws ProviderException >>>>>> when not initialized? >>>>>> No source code changes, but just updating javadoc to mention the >>>>>> possible failure case. >>>>>> Otherwise, JCK team expects a parameter object or null being >>>>>> returned. >>>>>> I filed a CSR to track the javadoc clarification. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> >>>>>> >>>> >>> > From weijun.wang at oracle.com Mon Jul 16 23:29:51 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 17 Jul 2018 07:29:51 +0800 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> Message-ID: <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> Valerie Would you like to retain the word "randomly generated" somewhere? Also, the SignatureSpi class needs to be updated in the same way. Can you also update the implementation in the MSCAPI Signature object? Thanks Max > On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: > > > No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 > Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 > > Thanks, > Valerie > > On 7/13/2018 11:05 AM, Valerie Peng wrote: >> >> Hmm, I like the idea of expanding null to cover both cases. >> I will explore it more and see. >> Thanks for the feedback, >> Valerie >> >> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>> >>>> >>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>> >>>> Sure. >>>> >>>>> >>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>> >>>> >>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>> >>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>> >>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>> >>>>> >>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>> >>>> I assume other getParameters() had not added it is because it happened they can return one. >>>> >>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>> >>>> For example, @throws SecurityException for File/Files operations. >>> >>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>> >>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>> >>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>> >>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>> >>> --Sean >>> >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>> Hi Valerie >>>>>> >>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>> >>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>> >>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>> >>>>>>> Hi Brad, >>>>>>> >>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >> > From xuelei.fan at oracle.com Tue Jul 17 00:05:10 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Jul 2018 17:05:10 -0700 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> <3d9cc98e-4c6c-9802-bab4-4ea94cda9907@oracle.com> Message-ID: <4c1ea589-4a07-5c5a-1300-95ae35b03031@oracle.com> On 7/16/2018 10:38 AM, Adam Petcher wrote: > New webrev: > http://cr.openjdk.java.net/~apetcher/8206929/webrev.02/ > PreSharedKeyExtension.java 447 if (result && !shc.isNegotiable(s.getSuite()) || 448 !clientHello.cipherSuites.contains(s.getSuite())) { May miss a pair of parentheses to join the "||" expression together. - if (result && !shc.isNegotiable(s.getSuite()) || - !clientHello.cipherSuites.contains(s.getSuite())) { + if (result && (!shc.isNegotiable(s.getSuite()) || + !clientHello.cipherSuites.contains(s.getSuite()))) { Otherwise, looks fine to me. Thanks, Xuelei From valerie.peng at oracle.com Tue Jul 17 01:46:21 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 16 Jul 2018 18:46:21 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> Message-ID: <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> Hi Max, Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. As for the part about "randomly generated", I am leaning toward not having it as I don't see? a value of specifying this. Webrev and CSR has been updated. New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ Thanks, Valerie On 7/16/2018 4:29 PM, Weijun Wang wrote: > Valerie > > Would you like to retain the word "randomly generated" somewhere? > > Also, the SignatureSpi class needs to be updated in the same way. > > Can you also update the implementation in the MSCAPI Signature object? > > Thanks > Max > >> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >> >> >> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >> >> Thanks, >> Valerie >> >> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>> Hmm, I like the idea of expanding null to cover both cases. >>> I will explore it more and see. >>> Thanks for the feedback, >>> Valerie >>> >>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>> >>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>> >>>>>> Hi Max, >>>>>> >>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>> Sure. >>>>> >>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>> >>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>> >>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>> >>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>> >>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>> >>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>> >>>>> For example, @throws SecurityException for File/Files operations. >>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>> >>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>> >>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>> >>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>> >>>> --Sean >>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>> Hi Valerie >>>>>>> >>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>> >>>>>>> Is it better to clarify when the implementation "may also fail"? >From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>> >>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>> >>>>>>>> Hi Brad, >>>>>>>> >>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> >>>>>>>> >>>>>>>> From sha.jiang at oracle.com Tue Jul 17 01:46:56 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 17 Jul 2018 09:46:56 +0800 Subject: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found In-Reply-To: References: <905d69d6-1112-0b53-9124-f53c783fa803@oracle.com> Message-ID: <8f887574-32ad-a45a-3319-c8eb8a80529a@oracle.com> Ping... John On 2018/7/13 09:15, sha.jiang at oracle.com wrote: > Could the new patch be reviewed? > http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ > > Thanks! > John > > On 2018/7/9 15:38, sha.jiang at oracle.com wrote: >> Hi Thomas, >> Thanks for your testing. >> >> I'm not sure that's a reasonable case. >> From my view, PKCS11Test.java simply checks if the NSS library >> directory exists. >> But it looks unnecessary to check every library file. >> In fact, if removing libnss3 or libsoftokn3's dependencies, like >> libnssutil3, the test also fails. >> >> However, I still re-checked my previous solution, and made a new >> webrev [1]. >> The constant badNSSVersion in PKCS11Test.java may not be fine. >> The static field nss_library in PKCS11Test.java can be softokn3 or >> nss3 for different tests. >> badNSSVersion should be checked after the target nss library is >> determined. >> And this checking should happen before the real testing, especially >> before security manager is enabled. >> So, a new extension method, exactly PKCS11Test::skipTest, was >> introduced, and the affected tests were modified accordingly. >> >> [1] http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ >> >> Best regards, >> John Jiang >> >> On 2018/7/4 14:15, Thomas St?fe wrote: >>> Hi, >>> >>> Unfortunately this is not enough. >>> >>> Running tests with your patch and NSS libs disabled (I renamed >>> libsoftokn3.so) yields the following errors: >>> >>> sun/security/pkcs11/Secmod/AddPrivateKey.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/AddTrustedCert.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/Crypto.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/GetPrivateKey.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/JksSetPrivateKey.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/LoadKeystore.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/TestNssDbSqlite.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/TrustAnchors.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> >>> >>> Excerpt from TestNssDbSqlite.jtr: >>> >>> ----------messages:(3/98)---------- >>> command: build TestNssDbSqlite >>> reason: Named class compiled on demand >>> elapsed time (seconds): 0.0 >>> result: Passed. All files up to date >>> >>> #section:main >>> ----------messages:(5/721)---------- >>> command: main TestNssDbSqlite >>> reason: User specified action: run main/othervm/timeout=120 >>> TestNssDbSqlite >>> Mode: othervm [/othervm specified] >>> Additional options from @modules: --add-modules >>> java.base,jdk.crypto.cryptoki --add-exports >>> java.base/sun.security.rsa=ALL-UNNAMED --add-exports >>> java.base/sun.security.provider=ALL-UNNAMED --add-exports >>> java.base/sun.security.jca=ALL-UNNAMED --add-exports >>> java.base/sun.security.tools.keytool=ALL-UNNAMED --add-exports >>> java.base/sun.security.x509=ALL-UNNAMED --add-exports >>> java.base/com.sun.crypto.provider=ALL-UNNAMED --add-exports >>> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED --add-opens >>> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED >>> elapsed time (seconds): 0.445 >>> ----------configuration:(11/604)---------- >>> Boot Layer >>> ?? add modules: java.base jdk.crypto.cryptoki >>> ?? add exports: java.base/com.sun.crypto.provider ALL-UNNAMED >>> ??????????????? java.base/sun.security.jca ALL-UNNAMED >>> ??????????????? java.base/sun.security.provider ALL-UNNAMED >>> ??????????????? java.base/sun.security.rsa ALL-UNNAMED >>> ??????????????? java.base/sun.security.tools.keytool ALL-UNNAMED >>> ??????????????? java.base/sun.security.x509 ALL-UNNAMED >>> ??????????????? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >>> ?? add opens:?? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >>> >>> ----------System.out:(1/64)---------- >>> Warning: can't find NSS librarys on this machine, skipping test >>> ----------System.err:(25/1633)---------- >>> java.security.ProviderException: Could not initialize NSS >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:218) >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) >>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) >>> at PKCS11Test.getSunPKCS11(PKCS11Test.java:152) >>> at TestNssDbSqlite.initializeProvider(TestNssDbSqlite.java:121) >>> at TestNssDbSqlite.initialize(TestNssDbSqlite.java:112) >>> at TestNssDbSqlite.main(TestNssDbSqlite.java:67) >>> 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:115) >>> at java.base/java.lang.Thread.run(Thread.java:834) >>> Caused by: java.io.IOException: NSS initialization failed >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:234) >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:213) >>> ... 14 more >>> >>> Kind Regards, Thomas >>> >>> >>> On Wed, Jul 4, 2018 at 7:36 AM,? wrote: >>>> Hi, >>>> If NSS libs are unavailable, PKCS11 tests fail when checking NSS >>>> version. >>>> This patch tries to fix this issue. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206258 >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.00/ >>>> >>>> Best regards, >>>> John Jiang >>>> >> >> > From weijun.wang at oracle.com Tue Jul 17 02:38:18 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 17 Jul 2018 10:38:18 +0800 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> Message-ID: <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. - At the end of the 1st paragraph, you have now > However, for signature algorithm such as "RSASSA-PSS", it requires parameters and the one used for signing must be supplied for verification to succeed. It may be better to return null instead of returning provider-specific default parameters. I suggest we don't talk about the reason (params must be the same for signing and verification), we can just say something like "If there is no provider-specific default parameters, this method should return null before user sets one". - null may be returned How about "{@code null} must be returned"? Everything else looks fine. Thanks Max > On Jul 17, 2018, at 9:46 AM, Valerie Peng wrote: > > Hi Max, > > Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. > > As for the part about "randomly generated", I am leaning toward not having it as I don't see a value of specifying this. > > Webrev and CSR has been updated. > > New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ > > Thanks, > Valerie > > On 7/16/2018 4:29 PM, Weijun Wang wrote: >> Valerie >> >> Would you like to retain the word "randomly generated" somewhere? >> >> Also, the SignatureSpi class needs to be updated in the same way. >> >> Can you also update the implementation in the MSCAPI Signature object? >> >> Thanks >> Max >> >>> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >>> >>> >>> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>> >>> Thanks, >>> Valerie >>> >>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>> Hmm, I like the idea of expanding null to cover both cases. >>>> I will explore it more and see. >>>> Thanks for the feedback, >>>> Valerie >>>> >>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>> >>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>>> Sure. >>>>>> >>>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>>> >>>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>>> >>>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>>> >>>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>>> >>>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>>> >>>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>>> >>>>>> For example, @throws SecurityException for File/Files operations. >>>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>>> >>>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>>> >>>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>>> >>>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>>> >>>>> --Sean >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>> Hi Valerie >>>>>>>> >>>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>>> >>>>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>>> >>>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> Hi Brad, >>>>>>>>> >>>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> >>>>>>>>> > From weijun.wang at oracle.com Tue Jul 17 02:54:25 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 17 Jul 2018 10:54:25 +0800 Subject: [11] RFR 8207318: KeyStore#getInstance(File, LoadStoreParameter) does not load the keystore In-Reply-To: <75913b5a-d3ea-a8cf-b654-1750ae77a1e6@oracle.com> References: <3BA37B8B-5BCA-489F-9BF7-99FEE46FFACF@oracle.com> <75913b5a-d3ea-a8cf-b654-1750ae77a1e6@oracle.com> Message-ID: <3562B583-14CB-403B-86AA-AE64E36C43C5@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8207318/webrev.00/ Here, when hasPassword is true, KeyStore::load(ins,pass) is implemented as keyStoreSpi.engineLoad(stream, password); initialized = true; so I simply add the same "initialized = true" to the else block. The ProbeKeystores.java test is updated with a size() call after getInstance(File,...) to ensure the keystore is loaded successfully. Thanks Max From sean.mullan at oracle.com Tue Jul 17 11:48:49 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Jul 2018 07:48:49 -0400 Subject: [11] RFR 8207318: KeyStore#getInstance(File, LoadStoreParameter) does not load the keystore In-Reply-To: <3562B583-14CB-403B-86AA-AE64E36C43C5@oracle.com> References: <3BA37B8B-5BCA-489F-9BF7-99FEE46FFACF@oracle.com> <75913b5a-d3ea-a8cf-b654-1750ae77a1e6@oracle.com> <3562B583-14CB-403B-86AA-AE64E36C43C5@oracle.com> Message-ID: <70b0b785-8daf-9fab-d7be-643ed631895f@oracle.com> Looks fine. --Sean On 7/16/18 10:54 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8207318/webrev.00/ > > Here, when hasPassword is true, KeyStore::load(ins,pass) is implemented as > > keyStoreSpi.engineLoad(stream, password); > initialized = true; > > so I simply add the same "initialized = true" to the else block. > > The ProbeKeystores.java test is updated with a size() call after getInstance(File,...) to ensure the keystore is loaded successfully. > > Thanks > Max > From adam.petcher at oracle.com Tue Jul 17 13:41:46 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 17 Jul 2018 09:41:46 -0400 Subject: RFR 8206929: Check session context for TLS session resumption In-Reply-To: <4c1ea589-4a07-5c5a-1300-95ae35b03031@oracle.com> References: <70f25b35-c6bc-a082-1523-4237b7b976d9@oracle.com> <8c6d91ea-ddd7-968c-ce9d-3739ac5311f0@oracle.com> <1badda54-bc24-2045-faff-f2bd7443e50f@oracle.com> <1eb9a8ab-89da-a97d-6a2a-bf12dc8d4cdf@oracle.com> <8c650b72-85ed-da5e-39ef-a1d2dbd88a84@oracle.com> <3d9cc98e-4c6c-9802-bab4-4ea94cda9907@oracle.com> <4c1ea589-4a07-5c5a-1300-95ae35b03031@oracle.com> Message-ID: On 7/16/2018 8:05 PM, Xuelei Fan wrote: > On 7/16/2018 10:38 AM, Adam Petcher wrote: >> New webrev: >> http://cr.openjdk.java.net/~apetcher/8206929/webrev.02/ >> > PreSharedKeyExtension.java > > ?447???????? if (result && !shc.isNegotiable(s.getSuite()) || > ?448???????????? !clientHello.cipherSuites.contains(s.getSuite())) { > > May miss a pair of parentheses to join the "||" expression together. > ?-???????? if (result && !shc.isNegotiable(s.getSuite()) || > ?-???????????? !clientHello.cipherSuites.contains(s.getSuite())) { > ?+???????? if (result && (!shc.isNegotiable(s.getSuite()) || > ?+???????????? !clientHello.cipherSuites.contains(s.getSuite()))) { > > Otherwise, looks fine to me. This will be fixed in the changeset that I push. Thanks. > > Thanks, > Xuelei From andrew.w.wong at oracle.com Thu Jul 5 18:57:32 2018 From: andrew.w.wong at oracle.com (Andrew Wong) Date: Thu, 5 Jul 2018 11:57:32 -0700 (PDT) Subject: (Open) RFR: 8205967: Remove sun/security/krb5/auto/UnboundSSL.java from ProblemList.txt Message-ID: <5ed1e57a-bf33-4c69-9102-426a4d6fa9b7@default> Dear Security Developer, Please review the following fix for bug id 8205967. The test associated with UnboundSSL.java was removed in a previous fix but was still listed in ProblemList.txt. ProblemList.txt has been updated accordingly by removing the test. http://cr.openjdk.java.net/~rhalade/andrew/8205967/webrev.00/ Thank you, Andrew Wong From norman.maurer at googlemail.com Tue Jul 10 16:57:59 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Tue, 10 Jul 2018 17:57:59 +0100 Subject: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later) In-Reply-To: References: Message-ID: <1BA5ED74-8EDC-49D3-8103-2262426C3E18@googlemail.com> thanks? used the wrong mailing list again :( > On 10. Jul 2018, at 17:57, Alan Bateman wrote: > > Forwarding to security-dev. > > On 10/07/2018 17:47, Norman Maurer wrote: >> Hi all, >> >> I just tried to run netty[1] testsuite with the latest jdk11 EA release (21) and saw some class-cast-exception with our custom SSLEngine implementation >> >> >> Caused by: java.lang.ClassCastException: class io.netty.handler.ssl.OpenSslEngine cannot be cast to class sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine is in unnamed module of loader 'app'; sun.security.ssl.SSLEngineImpl is in module java.base of loader 'bootstrap') >> at java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgorithmConstraints.java:93) >> at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:270) >> at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141) >> at io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:237) >> at io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:621) >> ... 27 more >> >> >> This change seems to be related to: >> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea >> >> I think you miss an instanceof check here in SSLAlgorithmConstraints before try to cast to SSLEngineImpl, as otherwise it will be impossible to use custom implementations of SSLEngine (which we have in netty) with the default TrustManagerFactory. >> >> Does this sound correct ? Should I open a bug-report ? >> >> Bye >> Norman >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n_nagraj321 at yahoo.com Tue Jul 17 09:45:09 2018 From: n_nagraj321 at yahoo.com (Nagaraju Chitimilla) Date: Tue, 17 Jul 2018 02:45:09 -0700 (MST) Subject: Trouble with SPNEGO In-Reply-To: <983580809.434597.1507747338267@webmail.123-reg.co.uk> References: <808499655.3685093.1507724794028@webmail.123-reg.co.uk> <983580809.434597.1507747338267@webmail.123-reg.co.uk> Message-ID: <1531820709212-0.post@n7.nabble.com> Hi Tom, Were you able to resolve this issue? Even i am facing the same issue with wildfly 8.2.1 app server. Thanks Nagaraju -- Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Security-Development-f69724.html From sean.mullan at oracle.com Tue Jul 17 20:14:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Jul 2018 16:14:13 -0400 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> Message-ID: <555010e2-f100-aa9c-df21-a386abfd1702@oracle.com> On 7/16/18 9:46 PM, Valerie Peng wrote: > As for the part about "randomly generated", I am leaning toward not > having it as I don't see? a value of specifying this. Hmm, I think it is important to continue to document the case where an implementation may return default/generated parameters even if it was not explicitly initialized with any. Maybe we don't need the "randomly generated" wording, but since that wording has been there for many releases, I would be hesitant to remove it. --Sean From valerie.peng at oracle.com Wed Jul 18 00:23:29 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 17 Jul 2018 17:23:29 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> Message-ID: Hi Max, Thanks for the suggestions. Please find comments inline. On 7/16/2018 7:38 PM, Weijun Wang wrote: > CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. > > - At the end of the 1st paragraph, you have now > >> However, for signature algorithm such as "RSASSA-PSS", it requires parameters and the one used for signing must be supplied for verification to succeed. It may be better to return null instead of returning provider-specific default parameters. > I suggest we don't talk about the reason (params must be the same for signing and verification), we can just say something like "If there is no provider-specific default parameters, this method should return null before user sets one". Alright, I initially didn't put down the reason. But since Brad asked about it, I add it to the CSR in case Joe raise the same question. I will update the CSR per your suggestion. > - null may be returned > > How about "{@code null} must be returned"? How about "should"? Is there a guideline on when to use "may/should/must"? Anyone knows? I thought must is mostly used in mandating input arguments must not be null. But don't recall it being used much for return values. Thanks, Valerie > > Everything else looks fine. > > Thanks > Max > >> On Jul 17, 2018, at 9:46 AM, Valerie Peng wrote: >> >> Hi Max, >> >> Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. >> >> As for the part about "randomly generated", I am leaning toward not having it as I don't see a value of specifying this. >> >> Webrev and CSR has been updated. >> >> New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >> >> Thanks, >> Valerie >> >> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>> Valerie >>> >>> Would you like to retain the word "randomly generated" somewhere? >>> >>> Also, the SignatureSpi class needs to be updated in the same way. >>> >>> Can you also update the implementation in the MSCAPI Signature object? >>> >>> Thanks >>> Max >>> >>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >>>> >>>> >>>> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>> I will explore it more and see. >>>>> Thanks for the feedback, >>>>> Valerie >>>>> >>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>>>> >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>>>> Sure. >>>>>>> >>>>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>>>> >>>>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>>>> >>>>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>>>> >>>>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>>>> >>>>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>>>> >>>>>>> For example, @throws SecurityException for File/Files operations. >>>>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>>>> >>>>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>>>> >>>>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>>>> >>>>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>>>> >>>>>> --Sean >>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>> Hi Valerie >>>>>>>>> >>>>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>>>> >>>>>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>>>> >>>>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> Hi Brad, >>>>>>>>>> >>>>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From timbrooks at fastmail.com Tue Jul 17 23:26:57 2018 From: timbrooks at fastmail.com (Tim Brooks) Date: Tue, 17 Jul 2018 17:26:57 -0600 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 Message-ID: My understanding is that when you are interested in closing the underlying socket when using the SSLEngine, you must call closeOutbound() and WRAP and UNWRAP until both isInboundDone() and isOutboundDone() return true. One edge case of this is if you are interested in closing the socket prior to the completion of a handshake. In JDK 10.0.1 (and I believe prior JDKs) this was the behavior for one way in which this arises: 1. Initiate handshake 2. UNWRAP data from client 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" 4. Call closeOutbound() (perhaps the server is shutting down and you want to close the connection). 5. Handshake status now returns "NEED_WRAP" JDK10: isInboundDone() - returns false isOutboundDone() - returns false A call to wrap() produces 7 bytes and status = CLOSED. Handshake status is now NEED_UNWRAP. isInboundDone() - returns false isOutboundDone() - returns true JDK11: isInboundDone() - returns true isOutboundDone() - returns false A call to wrap() throws the following exception: javax.net.ssl.SSLException: Cannot kickstart, the connection is broken or closed at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) at java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) I?m not sure what the procedure for closing a connection prior to handshake completion is for TLS. But obviously this is a scenario that can arise. It seems wrong to me that the state transitions for the SSLEngine do not handle this. The fact that ?isOutboundDone()? returns false, but I cannot WRAP seems to be an issue. From rajan.halade at oracle.com Wed Jul 18 00:31:38 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 17 Jul 2018 17:31:38 -0700 Subject: RFR: 8203230: update VerifyCACerts tests Message-ID: Please review this update for VerifyCACerts test to remove dependency on OpenJDK build. -------------------- @@ -25,7 +25,6 @@ ?/** ? * @test ? * @bug 8189131 8198240 8191844 8189949 8191031 8196141 8204923 8195774 8199779 - * @requires java.runtime.name ~= "OpenJDK.*" ? * @summary Check root CA entries in cacerts file ? */ ?import java.io.File; Thanks, Rajan From weijun.wang at oracle.com Wed Jul 18 00:50:20 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jul 2018 08:50:20 +0800 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> Message-ID: > On Jul 18, 2018, at 8:23 AM, Valerie Peng wrote: > > Hi Max, > > Thanks for the suggestions. Please find comments inline. > > On 7/16/2018 7:38 PM, Weijun Wang wrote: >> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >> >> - At the end of the 1st paragraph, you have now >> >>> However, for signature algorithm such as "RSASSA-PSS", it requires parameters and the one used for signing must be supplied for verification to succeed. It may be better to return null instead of returning provider-specific default parameters. >> I suggest we don't talk about the reason (params must be the same for signing and verification), we can just say something like "If there is no provider-specific default parameters, this method should return null before user sets one". > Alright, I initially didn't put down the reason. But since Brad asked about it, I add it to the CSR in case Joe raise the same question. I will update the CSR per your suggestion. >> - null may be returned >> >> How about "{@code null} must be returned"? > How about "should"? Is there a guideline on when to use "may/should/must"? Anyone knows? Even if there were guidelines on this for Java, I think we should just stick to https://tools.ietf.org/html/rfc2119, except that the capitalization is not necessary. "Must" is precise here. > I thought must is mostly used in mandating input arguments must not be null. But don't recall it being used much for return values. "must return" appears 39 times in java/ and "should return" 19 (simple grep, no line break). --Max > > Thanks, > Valerie > >> >> Everything else looks fine. >> >> Thanks >> Max >> >>> On Jul 17, 2018, at 9:46 AM, Valerie Peng wrote: >>> >>> Hi Max, >>> >>> Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. >>> >>> As for the part about "randomly generated", I am leaning toward not having it as I don't see a value of specifying this. >>> >>> Webrev and CSR has been updated. >>> >>> New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>> >>> Thanks, >>> Valerie >>> >>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>> Valerie >>>> >>>> Would you like to retain the word "randomly generated" somewhere? >>>> >>>> Also, the SignatureSpi class needs to be updated in the same way. >>>> >>>> Can you also update the implementation in the MSCAPI Signature object? >>>> >>>> Thanks >>>> Max >>>> >>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >>>>> >>>>> >>>>> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>> I will explore it more and see. >>>>>> Thanks for the feedback, >>>>>> Valerie >>>>>> >>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>>>>> Sure. >>>>>>>> >>>>>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>>>>> >>>>>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>>>>> >>>>>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>>>>> >>>>>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>>>>> >>>>>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>>>>> >>>>>>>> For example, @throws SecurityException for File/Files operations. >>>>>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>>>>> >>>>>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>>>>> >>>>>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>>>>> >>>>>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>> Hi Valerie >>>>>>>>>> >>>>>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>>>>> >>>>>>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>>>>> >>>>>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Brad, >>>>>>>>>>> >>>>>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > From valerie.peng at oracle.com Wed Jul 18 01:32:09 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 17 Jul 2018 18:32:09 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <555010e2-f100-aa9c-df21-a386abfd1702@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <555010e2-f100-aa9c-df21-a386abfd1702@oracle.com> Message-ID: Ok, I will try? add it back. Thanks, Valerie On 7/17/2018 1:14 PM, Sean Mullan wrote: > On 7/16/18 9:46 PM, Valerie Peng wrote: >> As for the part about "randomly generated", I am leaning toward not >> having it as I don't see? a value of specifying this. > > Hmm, I think it is important to continue to document the case where an > implementation may return default/generated parameters even if it was > not explicitly initialized with any. Maybe we don't need the "randomly > generated" wording, but since that wording has been there for many > releases, I would be hesitant to remove it. > > --Sean From valerie.peng at oracle.com Wed Jul 18 01:46:49 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 17 Jul 2018 18:46:49 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> Message-ID: Ok, let's use "must" then. I have also added the part about default parameters. Hope that all is clear now. Latest webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/ Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 Thanks, Valerie On 7/17/2018 5:50 PM, Weijun Wang wrote: > >> On Jul 18, 2018, at 8:23 AM, Valerie Peng wrote: >> >> Hi Max, >> >> Thanks for the suggestions. Please find comments inline. >> >> On 7/16/2018 7:38 PM, Weijun Wang wrote: >>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >>> >>> - At the end of the 1st paragraph, you have now >>> >>>> However, for signature algorithm such as "RSASSA-PSS", it requires parameters and the one used for signing must be supplied for verification to succeed. It may be better to return null instead of returning provider-specific default parameters. >>> I suggest we don't talk about the reason (params must be the same for signing and verification), we can just say something like "If there is no provider-specific default parameters, this method should return null before user sets one". >> Alright, I initially didn't put down the reason. But since Brad asked about it, I add it to the CSR in case Joe raise the same question. I will update the CSR per your suggestion. >>> - null may be returned >>> >>> How about "{@code null} must be returned"? >> How about "should"? Is there a guideline on when to use "may/should/must"? Anyone knows? > Even if there were guidelines on this for Java, I think we should just stick to https://tools.ietf.org/html/rfc2119, except that the capitalization is not necessary. > > "Must" is precise here. > >> I thought must is mostly used in mandating input arguments must not be null. But don't recall it being used much for return values. > "must return" appears 39 times in java/ and "should return" 19 (simple grep, no line break). > > --Max > >> Thanks, >> Valerie >> >>> Everything else looks fine. >>> >>> Thanks >>> Max >>> >>>> On Jul 17, 2018, at 9:46 AM, Valerie Peng wrote: >>>> >>>> Hi Max, >>>> >>>> Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. >>>> >>>> As for the part about "randomly generated", I am leaning toward not having it as I don't see a value of specifying this. >>>> >>>> Webrev and CSR has been updated. >>>> >>>> New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>>> Valerie >>>>> >>>>> Would you like to retain the word "randomly generated" somewhere? >>>>> >>>>> Also, the SignatureSpi class needs to be updated in the same way. >>>>> >>>>> Can you also update the implementation in the MSCAPI Signature object? >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >>>>>> >>>>>> >>>>>> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>>> I will explore it more and see. >>>>>>> Thanks for the feedback, >>>>>>> Valerie >>>>>>> >>>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>>>>>> Sure. >>>>>>>>> >>>>>>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>>>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>>>>>> >>>>>>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>>>>>> >>>>>>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>>>>>> >>>>>>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>>>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>>>>>> >>>>>>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>>>>>> >>>>>>>>> For example, @throws SecurityException for File/Files operations. >>>>>>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>>>>>> >>>>>>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>>>>>> >>>>>>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>>>>>> >>>>>>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>>>>>> >>>>>>>> --Sean >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>>> Hi Valerie >>>>>>>>>>> >>>>>>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>>>>>> >>>>>>>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>>>>>> >>>>>>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Brad, >>>>>>>>>>>> >>>>>>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Valerie >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From xuelei.fan at oracle.com Wed Jul 18 02:40:40 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 17 Jul 2018 19:40:40 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: References: Message-ID: Hi, We are working on the JDK 11 close issue. https://bugs.openjdk.java.net/browse/JDK-8207009 I appreciate if you can help test if we have a patch. Thanks, Xuelei On 7/17/2018 4:26 PM, Tim Brooks wrote: > My understanding is that when you are interested in closing the underlying socket when using the SSLEngine, you must call closeOutbound() and WRAP and UNWRAP until both isInboundDone() and isOutboundDone() return true. > > One edge case of this is if you are interested in closing the socket prior to the completion of a handshake. In JDK 10.0.1 (and I believe prior JDKs) this was the behavior for one way in which this arises: > > 1. Initiate handshake > 2. UNWRAP data from client > 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" > 4. Call closeOutbound() (perhaps the server is shutting down and you want to close the connection). > 5. Handshake status now returns "NEED_WRAP" > > JDK10: > > isInboundDone() - returns false > isOutboundDone() - returns false > > A call to wrap() produces 7 bytes and status = CLOSED. Handshake status is now NEED_UNWRAP. > > isInboundDone() - returns false > isOutboundDone() - returns true > > JDK11: > > isInboundDone() - returns true > isOutboundDone() - returns false > > A call to wrap() throws the following exception: > > javax.net.ssl.SSLException: Cannot kickstart, the connection is broken or closed > at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) > at java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) > at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) > at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) > at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) > > I?m not sure what the procedure for closing a connection prior to handshake completion is for TLS. But obviously this is a scenario that can arise. It seems wrong to me that the state transitions for the SSLEngine do not handle this. The fact that ?isOutboundDone()? returns false, but I cannot WRAP seems to be an issue. > From weijun.wang at oracle.com Wed Jul 18 03:38:34 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jul 2018 11:38:34 +0800 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> Message-ID: <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> Is it better to append the new lines to the 2nd paragraph? Thanks Max > On Jul 18, 2018, at 9:46 AM, Valerie Peng wrote: > > > Ok, let's use "must" then. I have also added the part about default parameters. > Hope that all is clear now. > > Latest webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/ > Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 > > Thanks, > Valerie > > On 7/17/2018 5:50 PM, Weijun Wang wrote: >> >>> On Jul 18, 2018, at 8:23 AM, Valerie Peng wrote: >>> >>> Hi Max, >>> >>> Thanks for the suggestions. Please find comments inline. >>> >>> On 7/16/2018 7:38 PM, Weijun Wang wrote: >>>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >>>> >>>> - At the end of the 1st paragraph, you have now >>>> >>>>> However, for signature algorithm such as "RSASSA-PSS", it requires parameters and the one used for signing must be supplied for verification to succeed. It may be better to return null instead of returning provider-specific default parameters. >>>> I suggest we don't talk about the reason (params must be the same for signing and verification), we can just say something like "If there is no provider-specific default parameters, this method should return null before user sets one". >>> Alright, I initially didn't put down the reason. But since Brad asked about it, I add it to the CSR in case Joe raise the same question. I will update the CSR per your suggestion. >>>> - null may be returned >>>> >>>> How about "{@code null} must be returned"? >>> How about "should"? Is there a guideline on when to use "may/should/must"? Anyone knows? >> Even if there were guidelines on this for Java, I think we should just stick to https://tools.ietf.org/html/rfc2119, except that the capitalization is not necessary. >> >> "Must" is precise here. >> >>> I thought must is mostly used in mandating input arguments must not be null. But don't recall it being used much for return values. >> "must return" appears 39 times in java/ and "should return" 19 (simple grep, no line break). >> >> --Max >> >>> Thanks, >>> Valerie >>> >>>> Everything else looks fine. >>>> >>>> Thanks >>>> Max >>>> >>>>> On Jul 17, 2018, at 9:46 AM, Valerie Peng wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. >>>>> >>>>> As for the part about "randomly generated", I am leaning toward not having it as I don't see a value of specifying this. >>>>> >>>>> Webrev and CSR has been updated. >>>>> >>>>> New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>>>> Valerie >>>>>> >>>>>> Would you like to retain the word "randomly generated" somewhere? >>>>>> >>>>>> Also, the SignatureSpi class needs to be updated in the same way. >>>>>> >>>>>> Can you also update the implementation in the MSCAPI Signature object? >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >>>>>>> >>>>>>> >>>>>>> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>>>> I will explore it more and see. >>>>>>>> Thanks for the feedback, >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>>>>>>> Sure. >>>>>>>>>> >>>>>>>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>>>>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>>>>>>> >>>>>>>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>>>>>>> >>>>>>>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>>>>>>> >>>>>>>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>>>>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>>>>>>> >>>>>>>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>>>>>>> >>>>>>>>>> For example, @throws SecurityException for File/Files operations. >>>>>>>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>>>>>>> >>>>>>>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>>>>>>> >>>>>>>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>>>>>>> >>>>>>>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>>>>>>> >>>>>>>>> --Sean >>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>>>> Hi Valerie >>>>>>>>>>>> >>>>>>>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>>>>>>> >>>>>>>>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>>>>>>> >>>>>>>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Brad, >>>>>>>>>>>>> >>>>>>>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Valerie >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > From jamil.j.nimeh at oracle.com Wed Jul 18 04:43:07 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 17 Jul 2018 21:43:07 -0700 Subject: RFR: JDK-8207237: SSLSocket#setEnabledCipherSuites is accepting empty string Message-ID: <373218d9-a29c-f622-50e1-7d8807c96944@oracle.com> Hello all, This fixes a recent finding in the new TLS code where we're accepting a cipher suite that is an empty string where in the past we would throw IllegalArgumentException.? This fix makes the new TLS implementation consistent with the old behavior. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8207237/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8207237 --Jamil From Xuelei.Fan at Oracle.Com Wed Jul 18 05:16:37 2018 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 17 Jul 2018 22:16:37 -0700 Subject: RFR: JDK-8207237: SSLSocket#setEnabledCipherSuites is accepting empty string In-Reply-To: <373218d9-a29c-f622-50e1-7d8807c96944@oracle.com> References: <373218d9-a29c-f622-50e1-7d8807c96944@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei > On Jul 17, 2018, at 9:43 PM, Jamil Nimeh wrote: > > Hello all, > > This fixes a recent finding in the new TLS code where we're accepting a cipher suite that is an empty string where in the past we would throw IllegalArgumentException. This fix makes the new TLS implementation consistent with the old behavior. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8207237/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8207237 > > --Jamil > > From weijun.wang at oracle.com Wed Jul 18 07:25:03 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jul 2018 15:25:03 +0800 Subject: RFR 8207250: setUseClientMode post handshake with the same value as before does not throw IAE Message-ID: <60689A4A-0824-49C8-819B-45A0322687E8@oracle.com> Please take a review at JBS: https://bugs.openjdk.java.net/browse/JDK-8207250 Fix: http://cr.openjdk.java.net/~weijun/8207250/webrev.00/ The status check should be performed no matter what the argument is. Thanks Max From weijun.wang at oracle.com Wed Jul 18 08:57:34 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jul 2018 16:57:34 +0800 Subject: [11] RFR 8202837: PBES2 AlgorithmId encoding error in PKCS12 KeyStore Message-ID: <8DF86C13-72D0-4808-B2CA-917B4A071F93@oracle.com> Please take a review at JBS: https://bugs.openjdk.java.net/browse/JDK-8202837 Fix: http://cr.openjdk.java.net/~weijun/8202837/webrev.00/ The redundant encoding/decoding of the extra PBES2 OID is removed. The encoding/decoding of keyLength and prf in PBKDF2-params is also made optional-aware. In PKCS12KeyStore, the decrypting of cert is fixed. See line 404 for the correct usage when decrypting the key. The new test contains a hardcoded PKCS 12 file, but I've included the exact commands to create it. Thanks Max From sean.mullan at oracle.com Wed Jul 18 11:23:16 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Jul 2018 07:23:16 -0400 Subject: RFR: 8203230: update VerifyCACerts tests In-Reply-To: References: Message-ID: Looks fine. --Sean On 7/17/18 8:31 PM, Rajan Halade wrote: > Please review this update for VerifyCACerts test to remove dependency on > OpenJDK build. > > -------------------- > @@ -25,7 +25,6 @@ > ?/** > ? * @test > ? * @bug 8189131 8198240 8191844 8189949 8191031 8196141 8204923 > 8195774 8199779 > - * @requires java.runtime.name ~= "OpenJDK.*" > ? * @summary Check root CA entries in cacerts file > ? */ > ?import java.io.File; > > Thanks, > Rajan From xuelei.fan at oracle.com Wed Jul 18 15:22:28 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 18 Jul 2018 08:22:28 -0700 Subject: RFR 8207250: setUseClientMode post handshake with the same value as before does not throw IAE In-Reply-To: <60689A4A-0824-49C8-819B-45A0322687E8@oracle.com> References: <60689A4A-0824-49C8-819B-45A0322687E8@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 7/18/2018 12:25 AM, Weijun Wang wrote: > Please take a review at > > JBS: https://bugs.openjdk.java.net/browse/JDK-8207250 > Fix: http://cr.openjdk.java.net/~weijun/8207250/webrev.00/ > > The status check should be performed no matter what the argument is. > > Thanks > Max > > From xuelei.fan at oracle.com Wed Jul 18 15:31:48 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 18 Jul 2018 08:31:48 -0700 Subject: [11] RFR 8202837: PBES2 AlgorithmId encoding error in PKCS12 KeyStore In-Reply-To: <8DF86C13-72D0-4808-B2CA-917B4A071F93@oracle.com> References: <8DF86C13-72D0-4808-B2CA-917B4A071F93@oracle.com> Message-ID: <59f3a33c-7260-04ea-b84e-afef36ce07b4@oracle.com> Looks fine to me except a minor nit. PBES2Parameters.java: --------------------- 282 String kdfAlgo = "HmacSHA1"; // default I may suggest you move the declaration down to line 314. It is clear about what the "default" means. Xuelei On 7/18/2018 1:57 AM, Weijun Wang wrote: > Please take a review at > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202837 > Fix: http://cr.openjdk.java.net/~weijun/8202837/webrev.00/ > > The redundant encoding/decoding of the extra PBES2 OID is removed. The encoding/decoding of keyLength and prf in PBKDF2-params is also made optional-aware. > > In PKCS12KeyStore, the decrypting of cert is fixed. See line 404 for the correct usage when decrypting the key. > > The new test contains a hardcoded PKCS 12 file, but I've included the exact commands to create it. > > Thanks > Max > From valerie.peng at oracle.com Wed Jul 18 17:29:14 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 18 Jul 2018 10:29:14 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> Message-ID: <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> Sean, Where do you think that we should add the part about "null must be returned ..." paragraph? At the end of first or second paragraph? I will go with majority. Valerie On 7/17/2018 8:38 PM, Weijun Wang wrote: > Is it better to append the new lines to the 2nd paragraph? > > Thanks > Max > >> On Jul 18, 2018, at 9:46 AM, Valerie Peng wrote: >> >> >> Ok, let's use "must" then. I have also added the part about default parameters. >> Hope that all is clear now. >> >> Latest webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/ >> Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >> >> Thanks, >> Valerie >> >> On 7/17/2018 5:50 PM, Weijun Wang wrote: >>>> On Jul 18, 2018, at 8:23 AM, Valerie Peng wrote: >>>> >>>> Hi Max, >>>> >>>> Thanks for the suggestions. Please find comments inline. >>>> >>>> On 7/16/2018 7:38 PM, Weijun Wang wrote: >>>>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >>>>> >>>>> - At the end of the 1st paragraph, you have now >>>>> >>>>>> However, for signature algorithm such as "RSASSA-PSS", it requires parameters and the one used for signing must be supplied for verification to succeed. It may be better to return null instead of returning provider-specific default parameters. >>>>> I suggest we don't talk about the reason (params must be the same for signing and verification), we can just say something like "If there is no provider-specific default parameters, this method should return null before user sets one". >>>> Alright, I initially didn't put down the reason. But since Brad asked about it, I add it to the CSR in case Joe raise the same question. I will update the CSR per your suggestion. >>>>> - null may be returned >>>>> >>>>> How about "{@code null} must be returned"? >>>> How about "should"? Is there a guideline on when to use "may/should/must"? Anyone knows? >>> Even if there were guidelines on this for Java, I think we should just stick to https://tools.ietf.org/html/rfc2119, except that the capitalization is not necessary. >>> >>> "Must" is precise here. >>> >>>> I thought must is mostly used in mandating input arguments must not be null. But don't recall it being used much for return values. >>> "must return" appears 39 times in java/ and "should return" 19 (simple grep, no line break). >>> >>> --Max >>> >>>> Thanks, >>>> Valerie >>>> >>>>> Everything else looks fine. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Jul 17, 2018, at 9:46 AM, Valerie Peng wrote: >>>>>> >>>>>> Hi Max, >>>>>> >>>>>> Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. >>>>>> >>>>>> As for the part about "randomly generated", I am leaning toward not having it as I don't see a value of specifying this. >>>>>> >>>>>> Webrev and CSR has been updated. >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>>>>> Valerie >>>>>>> >>>>>>> Would you like to retain the word "randomly generated" somewhere? >>>>>>> >>>>>>> Also, the SignatureSpi class needs to be updated in the same way. >>>>>>> >>>>>>> Can you also update the implementation in the MSCAPI Signature object? >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >>>>>>>> >>>>>>>> >>>>>>>> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>>>>> I will explore it more and see. >>>>>>>>> Thanks for the feedback, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>>>>>>>> Sure. >>>>>>>>>>> >>>>>>>>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>>>>>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>>>>>>>> >>>>>>>>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>>>>>>>> >>>>>>>>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>>>>>>>> >>>>>>>>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>>>>>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>>>>>>>> >>>>>>>>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>>>>>>>> >>>>>>>>>>> For example, @throws SecurityException for File/Files operations. >>>>>>>>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>>>>>>>> >>>>>>>>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>>>>>>>> >>>>>>>>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>>>>>>>> >>>>>>>>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>>>>>>>> >>>>>>>>>> --Sean >>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Valerie >>>>>>>>>>>> >>>>>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>>>>> Hi Valerie >>>>>>>>>>>>> >>>>>>>>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>>>>>>>> >>>>>>>>>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>>>>>>>> >>>>>>>>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Brad, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> From timbrooks at fastmail.com Wed Jul 18 18:51:28 2018 From: timbrooks at fastmail.com (Tim Brooks) Date: Wed, 18 Jul 2018 12:51:28 -0600 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: References: Message-ID: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> Yes. I can test once there is a patch. My inquiry was motivated by some work on Elasticsearch fyi. I can test a patch against that work. https://github.com/elastic/elasticsearch/issues/32144 - Tim > On Jul 17, 2018, at 8:40 PM, Xuelei Fan wrote: > > Hi, > > We are working on the JDK 11 close issue. > https://bugs.openjdk.java.net/browse/JDK-8207009 > > I appreciate if you can help test if we have a patch. > > Thanks, > Xuelei > > On 7/17/2018 4:26 PM, Tim Brooks wrote: >> My understanding is that when you are interested in closing the underlying socket when using the SSLEngine, you must call closeOutbound() and WRAP and UNWRAP until both isInboundDone() and isOutboundDone() return true. >> One edge case of this is if you are interested in closing the socket prior to the completion of a handshake. In JDK 10.0.1 (and I believe prior JDKs) this was the behavior for one way in which this arises: >> 1. Initiate handshake >> 2. UNWRAP data from client >> 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" >> 4. Call closeOutbound() (perhaps the server is shutting down and you want to close the connection). >> 5. Handshake status now returns "NEED_WRAP" >> JDK10: >> isInboundDone() - returns false >> isOutboundDone() - returns false >> A call to wrap() produces 7 bytes and status = CLOSED. Handshake status is now NEED_UNWRAP. >> isInboundDone() - returns false >> isOutboundDone() - returns true >> JDK11: >> isInboundDone() - returns true >> isOutboundDone() - returns false >> A call to wrap() throws the following exception: >> javax.net.ssl.SSLException: Cannot kickstart, the connection is broken or closed >> at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) >> at java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) >> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) >> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) >> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) >> I?m not sure what the procedure for closing a connection prior to handshake completion is for TLS. But obviously this is a scenario that can arise. It seems wrong to me that the state transitions for the SSLEngine do not handle this. The fact that ?isOutboundDone()? returns false, but I cannot WRAP seems to be an issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jul 19 14:28:37 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 19 Jul 2018 10:28:37 -0400 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> Message-ID: Hi Valerie, Max - I took a fresh look at this issue this morning. I think we are getting bogged down by trying to adjust within the current wording, which is somewhat awkward and hard to understand. So, I think it might be better to break up the wording into multiple sentences. Here's a cut at the rewording: /** * Returns the parameters used with this signature object. * *

If this signature has been previously initialized with parameters * (by calling the {@code setParameter} method), this method returns * the same parameters. If this signature has not been initialized with * parameters, this method may return a combination of default and * randomly generated parameter values if the underlying * signature implementation supports it and can successfully generate * them. Otherwise, {@code null} is returned. * * @return the parameters used with this signature, or {@code null} */ In the first sentence of the 2nd paragraph above, I wanted to first list the case where the signature is initialized with parameters, which is the most clear-cut case of what the behavior will be. Then I described the case where an implementation may return default/generated parameters -- and this is clearly marked "may" since it is optional. All other cases other than those two always return null, so I think this makes it easier to understand. --Sean On 7/18/18 1:29 PM, Valerie Peng wrote: > Sean, > > Where do you think that we should add the part about "null must be > returned ..." paragraph? At the end of first or second paragraph? > > I will go with majority. > > Valerie > > On 7/17/2018 8:38 PM, Weijun Wang wrote: >> Is it better to append the new lines to the 2nd paragraph? >> >> Thanks >> Max >> >>> On Jul 18, 2018, at 9:46 AM, Valerie Peng >>> wrote: >>> >>> >>> Ok, let's use "must" then. I have also added the part about default >>> parameters. >>> Hope that all is clear now. >>> >>> Latest webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/ >>> Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>> >>> Thanks, >>> Valerie >>> >>> On 7/17/2018 5:50 PM, Weijun Wang wrote: >>>>> On Jul 18, 2018, at 8:23 AM, Valerie Peng >>>>> wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> Thanks for the suggestions. Please find comments inline. >>>>> >>>>> On 7/16/2018 7:38 PM, Weijun Wang wrote: >>>>>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >>>>>> >>>>>> - At the end of the 1st paragraph, you have now >>>>>> >>>>>>> ?? However, for signature algorithm such as "RSASSA-PSS", it >>>>>>> requires parameters and the one used for signing must be supplied >>>>>>> for verification to succeed. It may be better to return null >>>>>>> instead of returning provider-specific default parameters. >>>>>> I suggest we don't talk about the reason (params must be the same >>>>>> for signing and verification), we can just say something like "If >>>>>> there is no provider-specific default parameters, this method >>>>>> should return null before user sets one". >>>>> Alright, I initially didn't put down the reason. But since Brad >>>>> asked about it, I add it to the CSR in case Joe raise the same >>>>> question. I will update the CSR per your suggestion. >>>>>> - null may be returned >>>>>> >>>>>> How about "{@code null} must be returned"? >>>>> How about "should"? Is there a guideline on when to use >>>>> "may/should/must"? Anyone knows? >>>> Even if there were guidelines on this for Java, I think we should >>>> just stick to https://tools.ietf.org/html/rfc2119, except that the >>>> capitalization is not necessary. >>>> >>>> "Must" is precise here. >>>> >>>>> I thought must is mostly used in mandating input arguments must not >>>>> be null. But don't recall it being used much for return values. >>>> "must return" appears 39 times in java/ and "should return" 19 >>>> (simple grep, no line break). >>>> >>>> --Max >>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>>> Everything else looks fine. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Jul 17, 2018, at 9:46 AM, Valerie Peng >>>>>>> wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> Good catch on the SignatureSpi class and SunMSCAPI provider, I >>>>>>> will include them. >>>>>>> >>>>>>> As for the part about "randomly generated", I am leaning toward >>>>>>> not having it as I don't see? a value of specifying this. >>>>>>> >>>>>>> Webrev and CSR has been updated. >>>>>>> >>>>>>> New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>>>>>> Valerie >>>>>>>> >>>>>>>> Would you like to retain the word "randomly generated" somewhere? >>>>>>>> >>>>>>>> Also, the SignatureSpi class needs to be updated in the same way. >>>>>>>> >>>>>>>> Can you also update the implementation in the MSCAPI Signature >>>>>>>> object? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> No issues found and it seems ok to return null if no parameters >>>>>>>>> is set. Thus, I have updated the webrev and CSR accordingly. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>>>>>> I will explore it more and see. >>>>>>>>>> Thanks for the feedback, >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>> >>>>>>>>>>>>> The javadoc is for Signature.getParameters(), so null can >>>>>>>>>>>>> be returned for signature algorithms which do not use >>>>>>>>>>>>> parameters, e.g. SHA256withDSA. As Signature class covers >>>>>>>>>>>>> all signature algorithms, I am not sure about mentioning >>>>>>>>>>>>> specific algorithm names as it may be lengthy and even >>>>>>>>>>>>> misleading unless we list out all applicable algorithms. >>>>>>>>>>>> Sure. >>>>>>>>>>>> >>>>>>>>>>>>> The part of "default and randomly generated" is inherited >>>>>>>>>>>>> from existing javadoc. I think "default" in the >>>>>>>>>>>>> aforementioned sentence means "hardcoded values". For >>>>>>>>>>>>> example, something like salt length will likely have a >>>>>>>>>>>>> fixed default value. Since we have no control over 3rd >>>>>>>>>>>>> party providers, I think we may have to keep this for >>>>>>>>>>>>> backward compatibility reason. For RSASSA-PSS sig >>>>>>>>>>>>> algorithm, it errors out if the required parameter is not >>>>>>>>>>>>> given. Thus, I added the sentence "If there are no >>>>>>>>>>>>> provider-specific default values, the underlying signature >>>>>>>>>>>>> implementation may also fail". >>>>>>>>>>>> OK, now I understand "a combination of default and randomly >>>>>>>>>>>> generated" means some part of the parameter is hardcoded and >>>>>>>>>>>> some is random. Anyway, let's keep it unchanged. >>>>>>>>>>>> >>>>>>>>>>>> Then, how about simply "If there are no provider-specific >>>>>>>>>>>> values" which covers both hardcoded and random values? >>>>>>>>>>>> >>>>>>>>>>>> "the underlying signature implementation may also fail" is >>>>>>>>>>>> still not clear to me. If I had not read the CSR I would >>>>>>>>>>>> thought an exception will be thrown when update/sign is called. >>>>>>>>>>>> >>>>>>>>>>>>> As for @throws, I debated about it. The main reason for not >>>>>>>>>>>>> adding one is consistency. Many (or should I say most) >>>>>>>>>>>>> security classes do not have @throws for ProviderException. >>>>>>>>>>>>> If we were to add @throws ProviderException here, we should >>>>>>>>>>>>> do it across the board. Besides, it is recommended to NOT >>>>>>>>>>>>> document runtime exceptions which callers are not prepared >>>>>>>>>>>>> to handle. >>>>>>>>>>>> I assume other getParameters() had not added it is because >>>>>>>>>>>> it happened they can return one. >>>>>>>>>>>> >>>>>>>>>>>> While people does not catch runtime exceptions but my >>>>>>>>>>>> understanding is that if you mentioned "fail" in the spec >>>>>>>>>>>> maybe it's better to add a @throws for it. >>>>>>>>>>>> >>>>>>>>>>>> For example, @throws SecurityException for File/Files >>>>>>>>>>>> operations. >>>>>>>>>>> Thinking more about this, I would be more inclined to >>>>>>>>>>> recommend that you change the meaning of null as the return >>>>>>>>>>> value to cover both cases: >>>>>>>>>>> >>>>>>>>>>> @return the parameters used with this signature, or null if >>>>>>>>>>> this signature does not use any parameters or does not >>>>>>>>>>> support default or randomly generated parameter values >>>>>>>>>>> >>>>>>>>>>> I don't think it is critical to make a distinction between >>>>>>>>>>> these 2 cases, because if the programmer doesn't initialize >>>>>>>>>>> it with parameters it will get a SignatureException anyway >>>>>>>>>>> when it tries to call sign or verify. >>>>>>>>>>> >>>>>>>>>>> It's not perfect, but probably the best you can do working >>>>>>>>>>> within the constraints of that API and minimizing >>>>>>>>>>> compatibility risk. >>>>>>>>>>> >>>>>>>>>>> --Sean >>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Valerie >>>>>>>>>>>>> >>>>>>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>>>>>> Hi Valerie >>>>>>>>>>>>>> >>>>>>>>>>>>>> About "it *may* return", do you mean it could also return >>>>>>>>>>>>>> null? My understanding is no. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is it better to clarify when the implementation "may also >>>>>>>>>>>>>> fail"? From the CSR, it's this method. Can you add a >>>>>>>>>>>>>> @throws spec to this method then? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, I am a little confused by "default and randomly >>>>>>>>>>>>>> generated". Does this actually mean "default (might be >>>>>>>>>>>>>> randomly generated)"? The "it may" sentence mentions >>>>>>>>>>>>>> "default and randomly generated" but the "if there" only >>>>>>>>>>>>>> says "default", which sounds like the the "randomly >>>>>>>>>>>>>> generated" case could be different. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Brad, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would you have time to review the fix for JDK-8206171: >>>>>>>>>>>>>>> Signature#getParameters for RSASSA-PSS throws >>>>>>>>>>>>>>> ProviderException when not initialized? >>>>>>>>>>>>>>> No source code changes, but just updating javadoc to >>>>>>>>>>>>>>> mention the possible failure case. >>>>>>>>>>>>>>> Otherwise, JCK team expects a parameter object or null >>>>>>>>>>>>>>> being returned. >>>>>>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > From mstjohns at comcast.net Thu Jul 19 19:36:30 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 19 Jul 2018 15:36:30 -0400 Subject: EC weirdness In-Reply-To: <98f90517-33a5-5c62-3c2b-89c75967874e@oracle.com> References: <98f90517-33a5-5c62-3c2b-89c75967874e@oracle.com> Message-ID: <979490f4-c208-1b9c-76ba-9aadf125fcac@comcast.net> On 7/16/2018 4:42 PM, Adam Petcher wrote: > I think the reason for the hard-coded curves is largely historical, > and I don't know of a security-related reason for it (other than the > prevention of insecure parameters). Though it has the additional > benefit that it simplifies the interface a lot, because the > implementation for a curve is not completely determined by the domain > parameters. Actually - they are.? An ECGenParameterSpec? (basically a named curve) is turned into an ECParameterSpec? (the actual curve and G stuff) which is turned into an AlgorithmSpecification of type (SunEC, EC) which strangely tries to do a reverse lookup of the parameter spec to get a name for the curve.?? (That's not exactly it, but its close in spirit). > The implementation may also need to know which optimized finite field > implementation, precomputed tables, etc to use. Looking up all of > these things at once can be a lot simpler than trying to specify them > over an interface. Nope - that's not it.? The underlying C code mostly uses generic bignum operations on the curve parameters rather than pre-computed things. My guess is that there were some dependencies on named curves in the EC library and the EC related stuff in the PKCS11 library. > > I'm trying to figure out if your problem motivates support for > arbitrary base points, or if there is another way to get what you > want. Is the base point a secret in your scheme? Either way, can you > implement your scheme using KeyAgreement (e.g. using the "base point" > as the public key and a random integer as the private key)? What if > ECDH KeyAgreement supported three-party Diffie-Hellman, or you extract > a point from generateSecret()? Would that help? In the scheme, G' is secret.? This is basically the EC version of https://en.wikipedia.org/wiki/SPEKE.? Two key pairs generated on P-256' (e.g. same curve params, but with G'), can use ECDH to get to the same shared secret.?? If your key pair wasn't generated with G', then you can't get to the same secret with someone who's key pair was. This is sort of an IOT experiment - I don't want to have to do an explicit authorization via a certificate binding a public key.? I can generate a group G', and have all the various devices generate a key pair using that G'.?? The ability to get a pairwise shared secret with another device proves the membership in the group to that other device and vice versa. The problem with using ECDH is that generic ECDH operations throw away the Y coordinate.? I can do xG' -> X'? using the SunEC ECDH, but what I actually get as a result is the scalar X'.x. I've been trying to avoid using external libraries, but I'll probably end up using the BC point math stuff to make this work. I may do a bit more archeology and see whether there are actual dependencies on the build in curve data (e.g. PKCS11).? If not, I may try and provide a patch refactoring out that limitation and doing a more thorough separation of the math from the packaging. Later, Mike > > On 7/13/2018 9:30 PM, Michael StJohns wrote: >> Hi - >> >> Every so often I run into some rather strange things in the way the >> Sun EC classes were built.? Most recently, I was trying to use the >> SunEC provider to do a PACE like protocol.? Basically, the idea was >> to be able to generate public key points on the P-256 curve, but with >> a different base point G (knowledge of G' or having a public key >> generated from G' would allow you to do a valid ECDH operation, keys >> with disjoint points would not). >> >> I was able to generate a normal key pair using ECGenParameterSpec >> with a name, so I grabbed the ECParameterSpec from the public key, >> made a copy of most of the stuff (curve, cofactor), but substituted >> the public point W from the key pair I'd just generated, and passed >> that in as G to the new parameter spec.? I tried to initialize the >> KPG with my *almost* P-256 spec, and it failed with "unsupported curve". >> >> Looking into the code and tracing through >> sun.crypto.ec.ECKeyPairGenerator to the native code, I'm once again >> surprised that all of the curves are hard coded into the C native >> code, rather than being passed in as data from the Java code. >> >> Is there a good security reason for hard coding the curves at the C >> level that I'm missing? >> >> This comes under the heading of unexpected behavior rather than a bug >> per se I think.?? Although - I'd *really* like to be able to pass a >> valid ECParameterSpec in to the generation process and get whatever >> keys are appropriate for that curve and base point. >> >> Later, Mike >> >> >> >> > From valerie.peng at oracle.com Thu Jul 19 21:18:45 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Jul 2018 14:18:45 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> Message-ID: <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> Hi Sean, Thanks for the suggestion, I like it. Max, any objection or concern before I update the webrev and CSR? Valerie On 7/19/2018 7:28 AM, Sean Mullan wrote: > Hi Valerie, Max - > > I took a fresh look at this issue this morning. I think we are getting > bogged down by trying to adjust within the current wording, which is > somewhat awkward and hard to understand. So, I think it might be > better to break up the wording into multiple sentences. Here's a cut > at the rewording: > > /** > ?* Returns the parameters used with this signature object. > ?* > ?*

If this signature has been previously initialized with parameters > ?* (by calling the {@code setParameter} method), this method returns > ?* the same parameters. If this signature has not been initialized with > ?* parameters, this method may return a combination of default and > ?* randomly generated parameter values if the underlying > ?* signature implementation supports it and can successfully generate > ?* them. Otherwise, {@code null} is returned. > ?* > ?* @return the parameters used with this signature, or {@code null} > ?*/ > > In the first sentence of the 2nd paragraph above, I wanted to first > list the case where the signature is initialized with parameters, > which is the most clear-cut case of what the behavior will be. Then I > described the case where an implementation may return > default/generated parameters -- and this is clearly marked "may" since > it is optional. All other cases other than those two always return > null, so I think this makes it easier to understand. > > --Sean > > On 7/18/18 1:29 PM, Valerie Peng wrote: >> Sean, >> >> Where do you think that we should add the part about "null must be >> returned ..." paragraph? At the end of first or second paragraph? >> >> I will go with majority. >> >> Valerie >> >> On 7/17/2018 8:38 PM, Weijun Wang wrote: >>> Is it better to append the new lines to the 2nd paragraph? >>> >>> Thanks >>> Max >>> >>>> On Jul 18, 2018, at 9:46 AM, Valerie Peng >>>> wrote: >>>> >>>> >>>> Ok, let's use "must" then. I have also added the part about default >>>> parameters. >>>> Hope that all is clear now. >>>> >>>> Latest webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/ >>>> Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 7/17/2018 5:50 PM, Weijun Wang wrote: >>>>>> On Jul 18, 2018, at 8:23 AM, Valerie Peng >>>>>> wrote: >>>>>> >>>>>> Hi Max, >>>>>> >>>>>> Thanks for the suggestions. Please find comments inline. >>>>>> >>>>>> On 7/16/2018 7:38 PM, Weijun Wang wrote: >>>>>>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >>>>>>> >>>>>>> - At the end of the 1st paragraph, you have now >>>>>>> >>>>>>>> ?? However, for signature algorithm such as "RSASSA-PSS", it >>>>>>>> requires parameters and the one used for signing must be >>>>>>>> supplied for verification to succeed. It may be better to >>>>>>>> return null instead of returning provider-specific default >>>>>>>> parameters. >>>>>>> I suggest we don't talk about the reason (params must be the >>>>>>> same for signing and verification), we can just say something >>>>>>> like "If there is no provider-specific default parameters, this >>>>>>> method should return null before user sets one". >>>>>> Alright, I initially didn't put down the reason. But since Brad >>>>>> asked about it, I add it to the CSR in case Joe raise the same >>>>>> question. I will update the CSR per your suggestion. >>>>>>> - null may be returned >>>>>>> >>>>>>> How about "{@code null} must be returned"? >>>>>> How about "should"? Is there a guideline on when to use >>>>>> "may/should/must"? Anyone knows? >>>>> Even if there were guidelines on this for Java, I think we should >>>>> just stick to https://tools.ietf.org/html/rfc2119, except that the >>>>> capitalization is not necessary. >>>>> >>>>> "Must" is precise here. >>>>> >>>>>> I thought must is mostly used in mandating input arguments must >>>>>> not be null. But don't recall it being used much for return values. >>>>> "must return" appears 39 times in java/ and "should return" 19 >>>>> (simple grep, no line break). >>>>> >>>>> --Max >>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>>> Everything else looks fine. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> On Jul 17, 2018, at 9:46 AM, Valerie Peng >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> Good catch on the SignatureSpi class and SunMSCAPI provider, I >>>>>>>> will include them. >>>>>>>> >>>>>>>> As for the part about "randomly generated", I am leaning toward >>>>>>>> not having it as I don't see? a value of specifying this. >>>>>>>> >>>>>>>> Webrev and CSR has been updated. >>>>>>>> >>>>>>>> New webrev: >>>>>>>> http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> Would you like to retain the word "randomly generated" somewhere? >>>>>>>>> >>>>>>>>> Also, the SignatureSpi class needs to be updated in the same way. >>>>>>>>> >>>>>>>>> Can you also update the implementation in the MSCAPI Signature >>>>>>>>> object? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No issues found and it seems ok to return null if no >>>>>>>>>> parameters is set. Thus, I have updated the webrev and CSR >>>>>>>>>> accordingly. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>>>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>>>>>>> I will explore it more and see. >>>>>>>>>>> Thanks for the feedback, >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The javadoc is for Signature.getParameters(), so null can >>>>>>>>>>>>>> be returned for signature algorithms which do not use >>>>>>>>>>>>>> parameters, e.g. SHA256withDSA. As Signature class covers >>>>>>>>>>>>>> all signature algorithms, I am not sure about mentioning >>>>>>>>>>>>>> specific algorithm names as it may be lengthy and even >>>>>>>>>>>>>> misleading unless we list out all applicable algorithms. >>>>>>>>>>>>> Sure. >>>>>>>>>>>>> >>>>>>>>>>>>>> The part of "default and randomly generated" is inherited >>>>>>>>>>>>>> from existing javadoc. I think "default" in the >>>>>>>>>>>>>> aforementioned sentence means "hardcoded values". For >>>>>>>>>>>>>> example, something like salt length will likely have a >>>>>>>>>>>>>> fixed default value. Since we have no control over 3rd >>>>>>>>>>>>>> party providers, I think we may have to keep this for >>>>>>>>>>>>>> backward compatibility reason. For RSASSA-PSS sig >>>>>>>>>>>>>> algorithm, it errors out if the required parameter is not >>>>>>>>>>>>>> given. Thus, I added the sentence "If there are no >>>>>>>>>>>>>> provider-specific default values, the underlying >>>>>>>>>>>>>> signature implementation may also fail". >>>>>>>>>>>>> OK, now I understand "a combination of default and >>>>>>>>>>>>> randomly generated" means some part of the parameter is >>>>>>>>>>>>> hardcoded and some is random. Anyway, let's keep it >>>>>>>>>>>>> unchanged. >>>>>>>>>>>>> >>>>>>>>>>>>> Then, how about simply "If there are no provider-specific >>>>>>>>>>>>> values" which covers both hardcoded and random values? >>>>>>>>>>>>> >>>>>>>>>>>>> "the underlying signature implementation may also fail" is >>>>>>>>>>>>> still not clear to me. If I had not read the CSR I would >>>>>>>>>>>>> thought an exception will be thrown when update/sign is >>>>>>>>>>>>> called. >>>>>>>>>>>>> >>>>>>>>>>>>>> As for @throws, I debated about it. The main reason for >>>>>>>>>>>>>> not adding one is consistency. Many (or should I say >>>>>>>>>>>>>> most) security classes do not have @throws for >>>>>>>>>>>>>> ProviderException. If we were to add @throws >>>>>>>>>>>>>> ProviderException here, we should do it across the board. >>>>>>>>>>>>>> Besides, it is recommended to NOT document runtime >>>>>>>>>>>>>> exceptions which callers are not prepared to handle. >>>>>>>>>>>>> I assume other getParameters() had not added it is because >>>>>>>>>>>>> it happened they can return one. >>>>>>>>>>>>> >>>>>>>>>>>>> While people does not catch runtime exceptions but my >>>>>>>>>>>>> understanding is that if you mentioned "fail" in the spec >>>>>>>>>>>>> maybe it's better to add a @throws for it. >>>>>>>>>>>>> >>>>>>>>>>>>> For example, @throws SecurityException for File/Files >>>>>>>>>>>>> operations. >>>>>>>>>>>> Thinking more about this, I would be more inclined to >>>>>>>>>>>> recommend that you change the meaning of null as the return >>>>>>>>>>>> value to cover both cases: >>>>>>>>>>>> >>>>>>>>>>>> @return the parameters used with this signature, or null if >>>>>>>>>>>> this signature does not use any parameters or does not >>>>>>>>>>>> support default or randomly generated parameter values >>>>>>>>>>>> >>>>>>>>>>>> I don't think it is critical to make a distinction between >>>>>>>>>>>> these 2 cases, because if the programmer doesn't initialize >>>>>>>>>>>> it with parameters it will get a SignatureException anyway >>>>>>>>>>>> when it tries to call sign or verify. >>>>>>>>>>>> >>>>>>>>>>>> It's not perfect, but probably the best you can do working >>>>>>>>>>>> within the constraints of that API and minimizing >>>>>>>>>>>> compatibility risk. >>>>>>>>>>>> >>>>>>>>>>>> --Sean >>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>>>>>>> Hi Valerie >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> About "it *may* return", do you mean it could also >>>>>>>>>>>>>>> return null? My understanding is no. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is it better to clarify when the implementation "may >>>>>>>>>>>>>>> also fail"? From the CSR, it's this method. Can you add >>>>>>>>>>>>>>> a @throws spec to this method then? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also, I am a little confused by "default and randomly >>>>>>>>>>>>>>> generated". Does this actually mean "default (might be >>>>>>>>>>>>>>> randomly generated)"? The "it may" sentence mentions >>>>>>>>>>>>>>> "default and randomly generated" but the "if there" only >>>>>>>>>>>>>>> says "default", which sounds like the the "randomly >>>>>>>>>>>>>>> generated" case could be different. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Brad, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Would you have time to review the fix for JDK-8206171: >>>>>>>>>>>>>>>> Signature#getParameters for RSASSA-PSS throws >>>>>>>>>>>>>>>> ProviderException when not initialized? >>>>>>>>>>>>>>>> No source code changes, but just updating javadoc to >>>>>>>>>>>>>>>> mention the possible failure case. >>>>>>>>>>>>>>>> Otherwise, JCK team expects a parameter object or null >>>>>>>>>>>>>>>> being returned. >>>>>>>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> From weijun.wang at oracle.com Thu Jul 19 22:13:46 2018 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Jul 2018 06:13:46 +0800 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> Message-ID: > ? 2018?7?20??05:18?Valerie Peng ??? > > Hi Sean, > > Thanks for the suggestion, I like it. Me too. > > Max, any objection or concern before I update the webrev and CSR? No. Thanks Max > > Valerie > > >> On 7/19/2018 7:28 AM, Sean Mullan wrote: >> Hi Valerie, Max - >> >> I took a fresh look at this issue this morning. I think we are getting bogged down by trying to adjust within the current wording, which is somewhat awkward and hard to understand. So, I think it might be better to break up the wording into multiple sentences. Here's a cut at the rewording: >> >> /** >> * Returns the parameters used with this signature object. >> * >> *

If this signature has been previously initialized with parameters >> * (by calling the {@code setParameter} method), this method returns >> * the same parameters. If this signature has not been initialized with >> * parameters, this method may return a combination of default and >> * randomly generated parameter values if the underlying >> * signature implementation supports it and can successfully generate >> * them. Otherwise, {@code null} is returned. >> * >> * @return the parameters used with this signature, or {@code null} >> */ >> >> In the first sentence of the 2nd paragraph above, I wanted to first list the case where the signature is initialized with parameters, which is the most clear-cut case of what the behavior will be. Then I described the case where an implementation may return default/generated parameters -- and this is clearly marked "may" since it is optional. All other cases other than those two always return null, so I think this makes it easier to understand. >> >> --Sean >> >>> On 7/18/18 1:29 PM, Valerie Peng wrote: >>> Sean, >>> >>> Where do you think that we should add the part about "null must be returned ..." paragraph? At the end of first or second paragraph? >>> >>> I will go with majority. >>> >>> Valerie >>> >>>> On 7/17/2018 8:38 PM, Weijun Wang wrote: >>>> Is it better to append the new lines to the 2nd paragraph? >>>> >>>> Thanks >>>> Max >>>> >>>>> On Jul 18, 2018, at 9:46 AM, Valerie Peng wrote: >>>>> >>>>> >>>>> Ok, let's use "must" then. I have also added the part about default parameters. >>>>> Hope that all is clear now. >>>>> >>>>> Latest webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/ >>>>> Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 7/17/2018 5:50 PM, Weijun Wang wrote: >>>>>>> On Jul 18, 2018, at 8:23 AM, Valerie Peng wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> Thanks for the suggestions. Please find comments inline. >>>>>>> >>>>>>>> On 7/16/2018 7:38 PM, Weijun Wang wrote: >>>>>>>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >>>>>>>> >>>>>>>> - At the end of the 1st paragraph, you have now >>>>>>>> >>>>>>>>> However, for signature algorithm such as "RSASSA-PSS", it requires parameters and the one used for signing must be supplied for verification to succeed. It may be better to return null instead of returning provider-specific default parameters. >>>>>>>> I suggest we don't talk about the reason (params must be the same for signing and verification), we can just say something like "If there is no provider-specific default parameters, this method should return null before user sets one". >>>>>>> Alright, I initially didn't put down the reason. But since Brad asked about it, I add it to the CSR in case Joe raise the same question. I will update the CSR per your suggestion. >>>>>>>> - null may be returned >>>>>>>> >>>>>>>> How about "{@code null} must be returned"? >>>>>>> How about "should"? Is there a guideline on when to use "may/should/must"? Anyone knows? >>>>>> Even if there were guidelines on this for Java, I think we should just stick to https://tools.ietf.org/html/rfc2119, except that the capitalization is not necessary. >>>>>> >>>>>> "Must" is precise here. >>>>>> >>>>>>> I thought must is mostly used in mandating input arguments must not be null. But don't recall it being used much for return values. >>>>>> "must return" appears 39 times in java/ and "should return" 19 (simple grep, no line break). >>>>>> >>>>>> --Max >>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>>> Everything else looks fine. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>>> On Jul 17, 2018, at 9:46 AM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. >>>>>>>>> >>>>>>>>> As for the part about "randomly generated", I am leaning toward not having it as I don't see a value of specifying this. >>>>>>>>> >>>>>>>>> Webrev and CSR has been updated. >>>>>>>>> >>>>>>>>> New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> Would you like to retain the word "randomly generated" somewhere? >>>>>>>>>> >>>>>>>>>> Also, the SignatureSpi class needs to be updated in the same way. >>>>>>>>>> >>>>>>>>>> Can you also update the implementation in the MSCAPI Signature object? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>>>>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>>>>>>>> I will explore it more and see. >>>>>>>>>>>> Thanks for the feedback, >>>>>>>>>>>> Valerie >>>>>>>>>>>> >>>>>>>>>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>>>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>>>>>>>>>>> Sure. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>>>>>>>>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>>>>>>>>>>> >>>>>>>>>>>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>>>>>>>>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>>>>>>>>>>> >>>>>>>>>>>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For example, @throws SecurityException for File/Files operations. >>>>>>>>>>>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>>>>>>>>>>> >>>>>>>>>>>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>>>>>>>>>>> >>>>>>>>>>>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>>>>>>>>>>> >>>>>>>>>>>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>>>>>>>>>>> >>>>>>>>>>>>> --Sean >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>>>>>>>> Hi Valerie >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Brad, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>>>>>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>>>>>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>> > From anthony.scarpino at oracle.com Fri Jul 20 00:02:54 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 19 Jul 2018 17:02:54 -0700 Subject: RFR(s): 8204196: integer cleanup Message-ID: <1575447c-251a-69c2-5736-7706e78cefe4@oracle.com> I need a review of some integer check cleanups. http://cr.openjdk.java.net/~ascarpino/int/webrev/ thanks Tony From xuelei.fan at oracle.com Fri Jul 20 00:13:11 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 19 Jul 2018 17:13:11 -0700 Subject: RFR(s): 8204196: integer cleanup In-Reply-To: <1575447c-251a-69c2-5736-7706e78cefe4@oracle.com> References: <1575447c-251a-69c2-5736-7706e78cefe4@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 7/19/2018 5:02 PM, Anthony Scarpino wrote: > I need a review of some integer check cleanups. > > http://cr.openjdk.java.net/~ascarpino/int/webrev/ > > thanks > > Tony From valerie.peng at oracle.com Fri Jul 20 01:23:08 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 19 Jul 2018 18:23:08 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> Message-ID: <19470b78-d52e-b476-d879-6959760c4f6a@oracle.com> Thanks Max and Sean for the review and suggestions. I have updated the webrev accordingly and finalized CSR. Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.04/ CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 Valerie On 7/19/2018 3:13 PM, Wang Weijun wrote: > >> ? 2018?7?20??05:18?Valerie Peng ??? >> >> Hi Sean, >> >> Thanks for the suggestion, I like it. > Me too. > >> Max, any objection or concern before I update the webrev and CSR? > No. > > Thanks > Max > >> Valerie >> >> >>> On 7/19/2018 7:28 AM, Sean Mullan wrote: >>> Hi Valerie, Max - >>> >>> I took a fresh look at this issue this morning. I think we are getting bogged down by trying to adjust within the current wording, which is somewhat awkward and hard to understand. So, I think it might be better to break up the wording into multiple sentences. Here's a cut at the rewording: >>> >>> /** >>> * Returns the parameters used with this signature object. >>> * >>> *

If this signature has been previously initialized with parameters >>> * (by calling the {@code setParameter} method), this method returns >>> * the same parameters. If this signature has not been initialized with >>> * parameters, this method may return a combination of default and >>> * randomly generated parameter values if the underlying >>> * signature implementation supports it and can successfully generate >>> * them. Otherwise, {@code null} is returned. >>> * >>> * @return the parameters used with this signature, or {@code null} >>> */ >>> >>> In the first sentence of the 2nd paragraph above, I wanted to first list the case where the signature is initialized with parameters, which is the most clear-cut case of what the behavior will be. Then I described the case where an implementation may return default/generated parameters -- and this is clearly marked "may" since it is optional. All other cases other than those two always return null, so I think this makes it easier to understand. >>> >>> --Sean >>> >>>> On 7/18/18 1:29 PM, Valerie Peng wrote: >>>> Sean, >>>> >>>> Where do you think that we should add the part about "null must be returned ..." paragraph? At the end of first or second paragraph? >>>> >>>> I will go with majority. >>>> >>>> Valerie >>>> >>>>> On 7/17/2018 8:38 PM, Weijun Wang wrote: >>>>> Is it better to append the new lines to the 2nd paragraph? >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Jul 18, 2018, at 9:46 AM, Valerie Peng wrote: >>>>>> >>>>>> >>>>>> Ok, let's use "must" then. I have also added the part about default parameters. >>>>>> Hope that all is clear now. >>>>>> >>>>>> Latest webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/ >>>>>> Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 7/17/2018 5:50 PM, Weijun Wang wrote: >>>>>>>> On Jul 18, 2018, at 8:23 AM, Valerie Peng wrote: >>>>>>>> >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> Thanks for the suggestions. Please find comments inline. >>>>>>>> >>>>>>>>> On 7/16/2018 7:38 PM, Weijun Wang wrote: >>>>>>>>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >>>>>>>>> >>>>>>>>> - At the end of the 1st paragraph, you have now >>>>>>>>> >>>>>>>>>> However, for signature algorithm such as "RSASSA-PSS", it requires parameters and the one used for signing must be supplied for verification to succeed. It may be better to return null instead of returning provider-specific default parameters. >>>>>>>>> I suggest we don't talk about the reason (params must be the same for signing and verification), we can just say something like "If there is no provider-specific default parameters, this method should return null before user sets one". >>>>>>>> Alright, I initially didn't put down the reason. But since Brad asked about it, I add it to the CSR in case Joe raise the same question. I will update the CSR per your suggestion. >>>>>>>>> - null may be returned >>>>>>>>> >>>>>>>>> How about "{@code null} must be returned"? >>>>>>>> How about "should"? Is there a guideline on when to use "may/should/must"? Anyone knows? >>>>>>> Even if there were guidelines on this for Java, I think we should just stick to https://tools.ietf.org/html/rfc2119, except that the capitalization is not necessary. >>>>>>> >>>>>>> "Must" is precise here. >>>>>>> >>>>>>>> I thought must is mostly used in mandating input arguments must not be null. But don't recall it being used much for return values. >>>>>>> "must return" appears 39 times in java/ and "should return" 19 (simple grep, no line break). >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> >>>>>>>>> Everything else looks fine. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>>> On Jul 17, 2018, at 9:46 AM, Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. >>>>>>>>>> >>>>>>>>>> As for the part about "randomly generated", I am leaning toward not having it as I don't see a value of specifying this. >>>>>>>>>> >>>>>>>>>> Webrev and CSR has been updated. >>>>>>>>>> >>>>>>>>>> New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>> Would you like to retain the word "randomly generated" somewhere? >>>>>>>>>>> >>>>>>>>>>> Also, the SignatureSpi class needs to be updated in the same way. >>>>>>>>>>> >>>>>>>>>>> Can you also update the implementation in the MSCAPI Signature object? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Valerie >>>>>>>>>>>> >>>>>>>>>>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>>>>>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>>>>>>>>> I will explore it more and see. >>>>>>>>>>>>> Thanks for the feedback, >>>>>>>>>>>>> Valerie >>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>>>>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>>>>>>>>>>>> Sure. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>>>>>>>>>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>>>>>>>>>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For example, @throws SecurityException for File/Files operations. >>>>>>>>>>>>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>>>>>>>>>>>> >>>>>>>>>>>>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Sean >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>>>>>>>>> Hi Valerie >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Brad, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>>>>>>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>>>>>>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>>>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> From openjdk at suche.org Fri Jul 20 06:52:01 2018 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Fri, 20 Jul 2018 08:52:01 +0200 Subject: Bug in HttpClient Message-ID: *Hi,* *i found an bug in JDK 10 with the new HttpClient. It does not handle responses wihtout contentlength correctly. Normally i would expect that the content is returned even without content length. Since i can not open an JDK bug i hope some person from the list can do it. Below is an example that show the problem.* * Gru? Thomas Lu?nig * *import*java.io.InputStream; *import*java.io.OutputStream; *import*java.net.InetSocketAddress;* import*java.net.ServerSocket;* import*java.net.Socket;* import*java.net.URI;* import*java.time.Duration;* import*javax.net.ServerSocketFactory; *import*jdk.incubator.http.HttpClient;* import*jdk.incubator.http.HttpRequest;* import*jdk.incubator.http.HttpResponse; *public**class*Client1 { *static**void*server(*final**boolean*withContentLength) { *try*(ServerSocket ss= ServerSocketFactory./getDefault/().createServerSocket()) { ss.setReuseAddress(*true*); ss.bind(*new*InetSocketAddress("127.0.0.1",80)); *final**byte*[] buf= *new**byte*[120400]; *try*(Socket s= ss.accept()) { ????????????????????????? System.*/out/*.println("Accepted: "+s.getRemoteSocketAddress()); *try*(? OutputStream os= s.getOutputStream();InputStream is= s.getInputStream()) { is.read(buf); is.read(buf); os.write("HTTP/1.0 200 OK\r\nConnection: close\r\nContent-Type: text/xml; charset=UTF-8\r\n".getBytes()); *if*(withContentLength) os.write("Content-Length: 4\r\n".getBytes()); os.write("\r\n".getBytes()); os.write("".getBytes()); os.flush(); ????????????????????????? } ??????????????????? } ???????????? } *catch*(*final*Throwable t) { t.printStackTrace(); } ????? } *static**void*client() { *try*{ *final*HttpClient client= HttpClient./newBuilder/().version(HttpClient.Version.*/HTTP_2/*).build(); *final*HttpResponse response= client ??? ??? ??? ??? ??? ??? ??? .send(HttpRequest./newBuilder/(*new*URI("http://127.0.0.1/test")).timeout(Duration./ofMillis/(120_000)) .POST(HttpRequest.BodyPublisher./fromString/("body")).build(), HttpResponse.BodyHandler./asString/()); ??????????????????? System.*/out/*.println("Received reply: "+ response.statusCode()); ??????????????????? System.*/out/*.println("Received body: "+ response.body()); ???????????? } *catch*(*final*Throwable t) { t.printStackTrace(); } ????? } *public**static**void*main(*final*String[] args) *throws*Exception { *new*Thread(()->/server/(*true*)).start(); /client/(); *new*Thread(()->/server/(*false*)).start(); /client/(); ?????? } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Fri Jul 20 07:38:26 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Jul 2018 09:38:26 +0200 Subject: Bug in HttpClient In-Reply-To: References: Message-ID: <27900b892ab06fad766652b87445450747bc1a8c.camel@redhat.com> Adding net-dev On Fri, 2018-07-20 at 08:52 +0200, Thomas Lu?nig wrote: > Hi, > i found an bug in JDK 10 with the new HttpClient. It does not handle > responses wihtout contentlength correctly. > Normally i would expect that the content is returned even without > content length. Since i can not open an JDK bug > i hope some person from the list can do it. Below is an example that > show the problem. > > Gru? Thomas Lu?nig > import java.io.InputStream; > import java.io.OutputStream; > import java.net.InetSocketAddress; > import java.net.ServerSocket; > import java.net.Socket; > import java.net.URI; > import java.time.Duration; > import javax.net.ServerSocketFactory; > import jdk.incubator.http.HttpClient; > import jdk.incubator.http.HttpRequest; > import jdk.incubator.http.HttpResponse; > public class Client1 { > static void server(final boolean withContentLength) { > try(ServerSocket ss = > ServerSocketFactory.getDefault().createServerSocket()) { > ss.setReuseAddress(true); > ss.bind(new InetSocketAddress("127.0.0.1",80)); > final byte[] buf = new byte[120400]; > try(Socket s = ss.accept()) { > System.out.println("Accepted: > "+s.getRemoteSocketAddress()); > try( OutputStream os = > s.getOutputStream(); InputStream is = s.getInputStream()) { > is.read(buf); > is.read(buf); > os.write("HTTP/1.0 200 > OK\r\nConnection: close\r\nContent-Type: text/xml; charset=UTF- > 8\r\n".getBytes()); > if(withContentLength) > os.write("Content-Length: 4\r\n".getBytes()); > os.write("\r\n".getBytes()); > os.write("".getBytes()); > os.flush(); > } > } > } catch(final Throwable t) { t.printStackTrace(); } > } > static void client() { > try { > final HttpClient client = > HttpClient.newBuilder().version(HttpClient.Version.HTTP_2).build(); > final HttpResponse response = client > .send(HttpRequest.newBuilder(new URI("htt > p://127.0.0.1/test")).timeout(Duration.ofMillis(120_000)) > > .POST(HttpRequest.BodyPublisher.fromString("body")).build(), > HttpResponse.BodyHandler.asString()); > System.out.println("Received reply: " + > response.statusCode()); > System.out.println("Received body: " + > response.body()); > } catch(final Throwable t) { t.printStackTrace(); } > } > public static void main(final String[] args) throws Exception > { > new Thread(()->server(true)).start(); > client(); > new Thread(()->server(false)).start(); > client(); > } > } From michael.x.mcmahon at oracle.com Fri Jul 20 10:35:54 2018 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 20 Jul 2018 11:35:54 +0100 Subject: Bug in HttpClient In-Reply-To: <27900b892ab06fad766652b87445450747bc1a8c.camel@redhat.com> References: <27900b892ab06fad766652b87445450747bc1a8c.camel@redhat.com> Message-ID: <5B51BB0A.3090205@oracle.com> Thanks for reporting this. I will look into it. - Michael On 20/07/2018, 08:38, Severin Gehwolf wrote: > Adding net-dev > > On Fri, 2018-07-20 at 08:52 +0200, Thomas Lu?nig wrote: >> Hi, >> i found an bug in JDK 10 with the new HttpClient. It does not handle >> responses wihtout contentlength correctly. >> Normally i would expect that the content is returned even without >> content length. Since i can not open an JDK bug >> i hope some person from the list can do it. Below is an example that >> show the problem. >> >> Gru? Thomas Lu?nig >> import java.io.InputStream; >> import java.io.OutputStream; >> import java.net.InetSocketAddress; >> import java.net.ServerSocket; >> import java.net.Socket; >> import java.net.URI; >> import java.time.Duration; >> import javax.net.ServerSocketFactory; >> import jdk.incubator.http.HttpClient; >> import jdk.incubator.http.HttpRequest; >> import jdk.incubator.http.HttpResponse; >> public class Client1 { >> static void server(final boolean withContentLength) { >> try(ServerSocket ss = >> ServerSocketFactory.getDefault().createServerSocket()) { >> ss.setReuseAddress(true); >> ss.bind(new InetSocketAddress("127.0.0.1",80)); >> final byte[] buf = new byte[120400]; >> try(Socket s = ss.accept()) { >> System.out.println("Accepted: >> "+s.getRemoteSocketAddress()); >> try( OutputStream os = >> s.getOutputStream(); InputStream is = s.getInputStream()) { >> is.read(buf); >> is.read(buf); >> os.write("HTTP/1.0 200 >> OK\r\nConnection: close\r\nContent-Type: text/xml; charset=UTF- >> 8\r\n".getBytes()); >> if(withContentLength) >> os.write("Content-Length: 4\r\n".getBytes()); >> os.write("\r\n".getBytes()); >> os.write("".getBytes()); >> os.flush(); >> } >> } >> } catch(final Throwable t) { t.printStackTrace(); } >> } >> static void client() { >> try { >> final HttpClient client = >> HttpClient.newBuilder().version(HttpClient.Version.HTTP_2).build(); >> final HttpResponse response = client >> .send(HttpRequest.newBuilder(new URI("htt >> p://127.0.0.1/test")).timeout(Duration.ofMillis(120_000)) >> >> .POST(HttpRequest.BodyPublisher.fromString("body")).build(), >> HttpResponse.BodyHandler.asString()); >> System.out.println("Received reply: " + >> response.statusCode()); >> System.out.println("Received body: " + >> response.body()); >> } catch(final Throwable t) { t.printStackTrace(); } >> } >> public static void main(final String[] args) throws Exception >> { >> new Thread(()->server(true)).start(); >> client(); >> new Thread(()->server(false)).start(); >> client(); >> } >> } From chris.hegarty at oracle.com Fri Jul 20 11:38:05 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 Jul 2018 12:38:05 +0100 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property Message-ID: JDK-8204233 added a new security property, `jdk.net.includeInExceptions`, to include additional, potentially security sensitive, information in exception detail messages in the networking area. The property accepts a comma separated list of values that specifies the particular type of extra detail information to add. Since its addition, in JDK 11, further uses have arisen to include additional, potentially security sensitive, information in exception detail messages in other areas, namely the java.util.jar APIs. See JDK-8205525, and http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054284.html Given that this mechanism will likely be used more generally across different parts of the platform, it seem prudent to rename the property to be less area-specific, thus allowing for additional argument values to be specified, like for example `jarPath`. The following are the suggested changes to the java.security file: $ hg extdiff -p diff -o -C1 src/java.base/share/conf/security/java.security *** 1062,1074 **** # ! # Enhanced exception message text # ! # By default, socket exception messages do not include potentially sensitive ! # information such as hostnames or port numbers. This property may be set to one ! # or more values, separated by commas, and with no white-space. Each value ! # represents a category of enhanced information. Currently, the only category defined ! # is "hostInfo" which enables more detailed information in the IOExceptions ! # thrown by java.net.Socket and also the socket types in the java.nio.channels package. ! # The setting in this file can be overridden by a system property of the same name ! # and with the same syntax and possible values. ! #jdk.net.includeInExceptions=hostInfo --- 1062,1084 ---- + + # + # Enhanced exception message information + # + # By default, several exception messages do not include potentially sensitive + # information such as file names, host names, or port numbers. This property may + # be used to enable categories of enhanced information in exception messages. + # The property accepts one or more comma separated values, each of which + # represents a category of enhanced exception message information to enable. + # Values are case-insensitive. Leading and trailing whitespaces, surrounding + # each value, are ignored. Unknown values are ignored. + # + # The categories, to enable enhanced exception message information, are: + # + # hostInfo - IOExceptions thrown by java.net.Socket and also the socket types + # in the java.nio.channels package will contain enhanced exception + # message information # ! # The property setting in this file can be overridden by a system property of ! # the same name, with the same syntax and possible values. # ! #jdk.includeInExceptions=hostInfo Full webrev: http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ -Chris. P.S. It appears that jtreg does not support quoted system property values with spaces on the @run line. I?ll file an issue against jtreg for this. From goetz.lindenmaier at sap.com Fri Jul 20 12:30:15 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 20 Jul 2018 12:30:15 +0000 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: References: Message-ID: <66ccf1fc97b64438b5c2d3c03fcd1948@sap.com> Hi, I scanned all the changes we did to exception messages in our internal VM, see below. We print paths and sockets in a row of places, but also other information. It's wide spread, while most is in java.base. We plan to contribute these messages in the near future. Thus it'll be useful if the property can be reused whenever some of this information is rated security relevant. Best regards, Goetz. java/io/FileOutputStream.java java/io/RandomAccessFile.java path java.base/unix/native/libjava/UnixFileSystem_md.c java.base/windows/native/libjava/WinNTFileSystem_md.c path java/util/jar/Manifest.java java/util/jar/Attributes.java path, position in file java/util/Timer.java print the errornous values (delay, period, time) jdk/internal/org/objectweb/asm/MethodWriter.java length of too long bytecode code libverify/check_code.c position of error, errroneous types java.base/share/native/libzip/zip_util.c path to zipped file java.base/share/native/libzip/zlib/inflate.c zip version information java.base/unix/native/libnet/Inet6AddressImpl.c java.base/share/native/libnet/net_util.c java.base/unix/native/libnet/PlainDatagramSocketImpl.c java.base/unix/native/libnet/PlainSocketImpl.c java.base/unix/native/libnet/SocketInputStream.c java.base/unix/native/libnet/SocketOutputStream.c java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c java.base/windows/native/libnet/DualStackPlainSocketImpl.c Information about sockets java.base/unix/native/libnio/ch/DatagramChannelImpl.c java.base/unix/native/libnio/ch/DatagramDispatcher.c socket java.base/unix/native/libnio/ch/FileChannelImpl.c size, protection codes of memory, file, java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c more detailed information about DISPLAY jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java inet address jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java path > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Chris Hegarty > Sent: Freitag, 20. Juli 2018 13:38 > To: core-libs-dev ; Security Dev OpenJDK > > Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions > security property > > JDK-8204233 added a new security property, `jdk.net.includeInExceptions`, > to include additional, potentially security sensitive, information in > exception detail messages in the networking area. The property accepts a > comma separated list of values that specifies the particular type of > extra detail information to add. > > Since its addition, in JDK 11, further uses have arisen to include > additional, potentially security sensitive, information in exception > detail messages in other areas, namely the java.util.jar APIs. See > JDK-8205525, and http://mail.openjdk.java.net/pipermail/core-libs- > dev/2018-July/054284.html > > Given that this mechanism will likely be used more generally across > different parts of the platform, it seem prudent to rename the property > to be less area-specific, thus allowing for additional argument values > to be specified, like for example `jarPath`. > > The following are the suggested changes to the java.security file: > > $ hg extdiff -p diff -o -C1 src/java.base/share/conf/security/java.security > *** 1062,1074 **** > > # > ! # Enhanced exception message text > # > ! # By default, socket exception messages do not include potentially sensitive > ! # information such as hostnames or port numbers. This property may be set > to one > ! # or more values, separated by commas, and with no white-space. Each > value > ! # represents a category of enhanced information. Currently, the only > category defined > ! # is "hostInfo" which enables more detailed information in the IOExceptions > ! # thrown by java.net.Socket and also the socket types in the > java.nio.channels package. > ! # The setting in this file can be overridden by a system property of the same > name > ! # and with the same syntax and possible values. > ! #jdk.net.includeInExceptions=hostInfo > --- 1062,1084 ---- > > + > + # > + # Enhanced exception message information > + # > + # By default, several exception messages do not include potentially > sensitive > + # information such as file names, host names, or port numbers. This > property may > + # be used to enable categories of enhanced information in exception > messages. > + # The property accepts one or more comma separated values, each of > which > + # represents a category of enhanced exception message information to > enable. > + # Values are case-insensitive. Leading and trailing whitespaces, surrounding > + # each value, are ignored. Unknown values are ignored. > + # > + # The categories, to enable enhanced exception message information, are: > + # > + # hostInfo - IOExceptions thrown by java.net.Socket and also the socket > types > + # in the java.nio.channels package will contain enhanced exception > + # message information > # > ! # The property setting in this file can be overridden by a system property of > ! # the same name, with the same syntax and possible values. > # > ! #jdk.includeInExceptions=hostInfo > > > Full webrev: > http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ > > -Chris. > > P.S. It appears that jtreg does not support quoted system property values > with spaces on the @run line. I?ll file an issue against jtreg for this. From Alan.Bateman at oracle.com Fri Jul 20 12:55:23 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Jul 2018 13:55:23 +0100 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: References: Message-ID: <1c8a463d-63eb-d2e9-118e-e37823942de8@oracle.com> On 20/07/2018 12:38, Chris Hegarty wrote: > JDK-8204233 added a new security property, `jdk.net.includeInExceptions`, > to include additional, potentially security sensitive, information in > exception detail messages in the networking area. The property accepts a > comma separated list of values that specifies the particular type of > extra detail information to add. > > : > > > Full webrev: > http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ > This looks good. For the follow-on jarPath then I think we should look at moving the parsing to somewhere in java.base so that it can be used by other code in the module. -Alan From roger.riggs at oracle.com Fri Jul 20 13:52:29 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 20 Jul 2018 09:52:29 -0400 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: References: Message-ID: Hi Chris, It is very unusual for the processing of system properties to do *any* parsing except for delimiters including removing spaces, etc.? It complicates the handling and sets a bad precedent that makes it more complex for users and developers to know how to set property values. The whitespace trimming should be removed. $.02, Roger On 7/20/18 7:38 AM, Chris Hegarty wrote: > JDK-8204233 added a new security property, `jdk.net.includeInExceptions`, > to include additional, potentially security sensitive, information in > exception detail messages in the networking area. The property accepts a > comma separated list of values that specifies the particular type of > extra detail information to add. > > Since its addition, in JDK 11, further uses have arisen to include > additional, potentially security sensitive, information in exception > detail messages in other areas, namely the java.util.jar APIs. See > JDK-8205525, and http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054284.html > > Given that this mechanism will likely be used more generally across > different parts of the platform, it seem prudent to rename the property > to be less area-specific, thus allowing for additional argument values > to be specified, like for example `jarPath`. > > The following are the suggested changes to the java.security file: > > $ hg extdiff -p diff -o -C1 src/java.base/share/conf/security/java.security > *** 1062,1074 **** > > # > ! # Enhanced exception message text > # > ! # By default, socket exception messages do not include potentially sensitive > ! # information such as hostnames or port numbers. This property may be set to one > ! # or more values, separated by commas, and with no white-space. Each value > ! # represents a category of enhanced information. Currently, the only category defined > ! # is "hostInfo" which enables more detailed information in the IOExceptions > ! # thrown by java.net.Socket and also the socket types in the java.nio.channels package. > ! # The setting in this file can be overridden by a system property of the same name > ! # and with the same syntax and possible values. > ! #jdk.net.includeInExceptions=hostInfo > --- 1062,1084 ---- > > + > + # > + # Enhanced exception message information > + # > + # By default, several exception messages do not include potentially sensitive > + # information such as file names, host names, or port numbers. This property may > + # be used to enable categories of enhanced information in exception messages. > + # The property accepts one or more comma separated values, each of which > + # represents a category of enhanced exception message information to enable. > + # Values are case-insensitive. Leading and trailing whitespaces, surrounding > + # each value, are ignored. Unknown values are ignored. > + # > + # The categories, to enable enhanced exception message information, are: > + # > + # hostInfo - IOExceptions thrown by java.net.Socket and also the socket types > + # in the java.nio.channels package will contain enhanced exception > + # message information > # > ! # The property setting in this file can be overridden by a system property of > ! # the same name, with the same syntax and possible values. > # > ! #jdk.includeInExceptions=hostInfo > > > Full webrev: > http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ > > -Chris. > > P.S. It appears that jtreg does not support quoted system property values > with spaces on the @run line. I?ll file an issue against jtreg for this. > From chris.hegarty at oracle.com Fri Jul 20 14:18:47 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 Jul 2018 15:18:47 +0100 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: References: Message-ID: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> Roger, > On 20 Jul 2018, at 14:52, Roger Riggs wrote: > > Hi Chris, > > It is very unusual for the processing of system properties to do *any* parsing except for delimiters > including removing spaces, etc. It complicates the handling and sets a bad precedent > that makes it more complex for users and developers to know how to set property values. > The whitespace trimming should be removed. The addition of the whitespace trimming was to clarify the intent of the existing wording regarding whitespace. It was not intended to set a precedent, good or bad. Regardless of any subjective opinion, whitespace are allowable within system property values, so it?s a matter of whether or not we want to deal with them explicitly or just leave it as an implementation detail. I?m ok to drop the trimming if you feel strongly about it. But just to note that this now diverges even more from the original. -Chris. > $.02, Roger > >> http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ >> >> -Chris. >> >> P.S. It appears that jtreg does not support quoted system property values >> with spaces on the @run line. I?ll file an issue against jtreg for this. >> > From roger.riggs at oracle.com Fri Jul 20 14:36:54 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 20 Jul 2018 10:36:54 -0400 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> References: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> Message-ID: <1caeb924-26d2-14f6-9b0d-6f1cfc81a9ea@oracle.com> Hi Chris, It is important to be clear about how whitespace is treated and within the java.security file there are other uses that explicitly define how whitespace is used. I am more concerned about how command line properties are understood and used how we have to document them. Allowing whitespace quickly gets bogged down in how shells handle quotes, telling people they have to quote them and when/whether you have to quote the quotes. Having a consistent treatment of command line and security properties keeps the story simple and easier to support. The jdk.serialFilter property had the same issue and is explicit in the java.security file that spaces are just another character and are not treated specially. Its a slippery slope, if we start compensating/ignoring whitespace in some properties then we will have to keep explaining how some are treated differently. I would keep the original non-whitespace description. Case-insensistive compares are another slippery slope but make a bit more sense for usability. $.02, Roger On 7/20/18 10:18 AM, Chris Hegarty wrote: > Roger, > >> On 20 Jul 2018, at 14:52, Roger Riggs wrote: >> >> Hi Chris, >> >> It is very unusual for the processing of system properties to do *any* parsing except for delimiters >> including removing spaces, etc. It complicates the handling and sets a bad precedent >> that makes it more complex for users and developers to know how to set property values. >> The whitespace trimming should be removed. > The addition of the whitespace trimming was to clarify the intent of > the existing wording regarding whitespace. It was not intended to > set a precedent, good or bad. > > Regardless of any subjective opinion, whitespace are allowable > within system property values, so it?s a matter of whether or not > we want to deal with them explicitly or just leave it as an > implementation detail. > > I?m ok to drop the trimming if you feel strongly about it. But just > to note that this now diverges even more from the original. > > -Chris. > >> $.02, Roger >> >>> http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ >>> >>> -Chris. >>> >>> P.S. It appears that jtreg does not support quoted system property values >>> with spaces on the @run line. I?ll file an issue against jtreg for this. >>> From chris.hegarty at oracle.com Fri Jul 20 15:08:21 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 Jul 2018 16:08:21 +0100 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: <1caeb924-26d2-14f6-9b0d-6f1cfc81a9ea@oracle.com> References: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> <1caeb924-26d2-14f6-9b0d-6f1cfc81a9ea@oracle.com> Message-ID: <0A75D4BE-B31B-4AD4-A526-25F32162062A@oracle.com> Roger, > On 20 Jul 2018, at 15:36, Roger Riggs wrote: > > Hi Chris, > > It is important to be clear about how whitespace is treated and within the java.security file > there are other uses that explicitly define how whitespace is used. Right, and the usages are already inconsistent. Nothing we can do about that now. > I am more concerned about how command line properties are understood and used how we have to document them. > Allowing whitespace quickly gets bogged down in how shells handle quotes, telling people they have to > quote them and when/whether you have to quote the quotes. You cannot disallow whitespace, simple ignore them or consider them part of the value. > Having a consistent treatment of command line and security properties keeps the > story simple and easier to support. This file is already inconsistent, trimming happens in some cases. Whitespaces are either trimmed, ignored, or considered as like any other character. > The jdk.serialFilter property had the same issue and is explicit in the java.security file > that spaces are just another character and are not treated specially. This is a reasonable position. > Its a slippery slope, if we start compensating/ignoring whitespace in some properties > then we will have to keep explaining how some are treated differently. > I would keep the original non-whitespace description. Original: "This property may be set to one or more values, separated by commas, and with no white-space? This is ambiguous, and needs to be clarified. Surely, it is better to use the same wording as the serial filter: "Whitespace is significant and is considered part of the value." > Case-insensistive compares are another slippery slope but make a bit more sense for usability. The complete updated text: # # Enhanced exception message information # # By default, several exception messages do not include potentially sensitive # information such as file names, host names, or port numbers. This property may # be used to enable categories of enhanced information in exception messages. # The property accepts one or more comma separated values, each of which # represents a category of enhanced exception message information to enable. # Values are case-insensitive. Whitespace is significant and is considered part # of the value. Unknown values are ignored. # # The categories, to enable enhanced exception message information, are: # # hostInfo - IOExceptions thrown by java.net.Socket and also the socket types # in the java.nio.channels package will contain enhanced exception # message information # # The property setting in this file can be overridden by a system property of # the same name, with the same syntax and possible values. # #jdk.includeInExceptions=hostInfo -Chris. From roger.riggs at oracle.com Fri Jul 20 15:15:20 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 20 Jul 2018 11:15:20 -0400 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: <0A75D4BE-B31B-4AD4-A526-25F32162062A@oracle.com> References: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> <1caeb924-26d2-14f6-9b0d-6f1cfc81a9ea@oracle.com> <0A75D4BE-B31B-4AD4-A526-25F32162062A@oracle.com> Message-ID: <675acacb-1c17-3880-b5f2-1f0565ddb0ee@oracle.com> Hi Chris, The updated text is fine. Thanks for your consideration. The overlapping of configure options between java.security, net.properties, etc. and command line options is something to keep an eye on. Roger On 7/20/18 11:08 AM, Chris Hegarty wrote: > Roger, > >> On 20 Jul 2018, at 15:36, Roger Riggs wrote: >> >> Hi Chris, >> >> It is important to be clear about how whitespace is treated and within the java.security file >> there are other uses that explicitly define how whitespace is used. > Right, and the usages are already inconsistent. Nothing we can > do about that now. > >> I am more concerned about how command line properties are understood and used how we have to document them. >> Allowing whitespace quickly gets bogged down in how shells handle quotes, telling people they have to >> quote them and when/whether you have to quote the quotes. > You cannot disallow whitespace, simple ignore them or consider > them part of the value. > >> Having a consistent treatment of command line and security properties keeps the >> story simple and easier to support. > This file is already inconsistent, trimming happens in some cases. > Whitespaces are either trimmed, ignored, or considered as like > any other character. > >> The jdk.serialFilter property had the same issue and is explicit in the java.security file >> that spaces are just another character and are not treated specially. > This is a reasonable position. > >> Its a slippery slope, if we start compensating/ignoring whitespace in some properties >> then we will have to keep explaining how some are treated differently. >> I would keep the original non-whitespace description. > Original: "This property may be set to one or more values, > separated by commas, and with no white-space? > > This is ambiguous, and needs to be clarified. Surely, it is > better to use the same wording as the serial filter: > > "Whitespace is significant and is considered part of the value." > >> Case-insensistive compares are another slippery slope but make a bit more sense for usability. > The complete updated text: > > # > # Enhanced exception message information > # > # By default, several exception messages do not include potentially sensitive > # information such as file names, host names, or port numbers. This property may > # be used to enable categories of enhanced information in exception messages. > # The property accepts one or more comma separated values, each of which > # represents a category of enhanced exception message information to enable. > # Values are case-insensitive. Whitespace is significant and is considered part > # of the value. Unknown values are ignored. > # > # The categories, to enable enhanced exception message information, are: > # > # hostInfo - IOExceptions thrown by java.net.Socket and also the socket types > # in the java.nio.channels package will contain enhanced exception > # message information > # > # The property setting in this file can be overridden by a system property of > # the same name, with the same syntax and possible values. > # > #jdk.includeInExceptions=hostInfo > > -Chris. > From chris.hegarty at oracle.com Fri Jul 20 15:33:06 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 Jul 2018 16:33:06 +0100 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: <675acacb-1c17-3880-b5f2-1f0565ddb0ee@oracle.com> References: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> <1caeb924-26d2-14f6-9b0d-6f1cfc81a9ea@oracle.com> <0A75D4BE-B31B-4AD4-A526-25F32162062A@oracle.com> <675acacb-1c17-3880-b5f2-1f0565ddb0ee@oracle.com> Message-ID: <348DBF4E-7767-4CF1-B8D9-8AAFE937332C@oracle.com> > On 20 Jul 2018, at 16:15, Roger Riggs wrote: > > Hi Chris, > > The updated text is fine. > Thanks for your consideration. Updated webrev as discussed. http://cr.openjdk.java.net/~chegar/8207846/webrev.01/ -Chris. From sean.mullan at oracle.com Fri Jul 20 17:07:51 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Jul 2018 13:07:51 -0400 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: <0A75D4BE-B31B-4AD4-A526-25F32162062A@oracle.com> References: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> <1caeb924-26d2-14f6-9b0d-6f1cfc81a9ea@oracle.com> <0A75D4BE-B31B-4AD4-A526-25F32162062A@oracle.com> Message-ID: <3c5c5465-492b-b740-77fc-f5a5c042d283@oracle.com> On 7/20/18 11:08 AM, Chris Hegarty wrote: > This is ambiguous, and needs to be clarified. Surely, it is > better to use the same wording as the serial filter: > > "Whitespace is significant and is considered part of the value." Kind of on the fence on that one. If this were a general property/value format, I would agree, but these values are fixed and not potentially complicated expressions. For example, does this mean: jdk.includeInExceptions=hostInfo,jarInfo and jdk.includeInExceptions=hostInfo, jarInfo are different? And I assume the latter " jarInfo" would be ignored? If you are strongly in favor of this, I would highly recommend logging a warning when there is an unknown value, otherwise typos and such would be hard to detect (although this doesn't necessarily need to be in the specification). --Sean From anthony.scarpino at oracle.com Fri Jul 20 19:18:24 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 20 Jul 2018 12:18:24 -0700 Subject: RFR(xs) 8206968: java/net/httpclient/CancelledResponse.java fails after TLS1.3 changeset Message-ID: <0f591ab6-6244-3f2e-795d-877df633ad4f@oracle.com> Below is a simple fix that the test intermittently fails on. The problem is believed to be that the read thread sees a close_notify which cause the read thread to do a write operation. That write operation conflicts with the on-going write thread usage of the Cipher object doing the encryption. Synchronizing the methods fixes the conflict and performance should not be affected as encrypt operations should always be single-threaded. Other solutions, like creating cipher objects or a cipher object pool would be a bigger performance hit in this limited failure situation. Because the test is intermittent, I've never been able to reproduce it. Given different exceptions related to cipher initialization have occured in the encrypt method, I believe this will resolve the problem. http://cr.openjdk.java.net/~ascarpino/8206968/webrev/ Tony From weijun.wang at oracle.com Sat Jul 21 06:33:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 21 Jul 2018 14:33:17 +0800 Subject: [11] RFR 8207223: SSL Handshake failures are reported with more generic SSLException Message-ID: <145983FE-E141-40BD-9533-78940B6FF705@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8207223/webrev.00/ UNEXPECTED_MESSAGE indicates a flaw in the peer's protocol implementation, which should result in a SSLProtocolException. Thanks Max From xuelei.fan at oracle.com Sat Jul 21 13:40:31 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 21 Jul 2018 06:40:31 -0700 Subject: [11] RFR 8207223: SSL Handshake failures are reported with more generic SSLException In-Reply-To: <145983FE-E141-40BD-9533-78940B6FF705@oracle.com> References: <145983FE-E141-40BD-9533-78940B6FF705@oracle.com> Message-ID: Looks fine to me. Might be better if enclosing the assigning expression in parentheses. Xuelei On 7/20/2018 11:33 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8207223/webrev.00/ > > UNEXPECTED_MESSAGE indicates a flaw in the peer's protocol implementation, which should result in a SSLProtocolException. > > Thanks > Max > From weijun.wang at oracle.com Sat Jul 21 13:42:50 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 21 Jul 2018 21:42:50 +0800 Subject: [11] RFR 8207223: SSL Handshake failures are reported with more generic SSLException In-Reply-To: References: <145983FE-E141-40BD-9533-78940B6FF705@oracle.com> Message-ID: <49FECB83-1BF6-4B8F-A782-8539F9940A53@oracle.com> > On Jul 21, 2018, at 9:40 PM, Xuelei Fan wrote: > > Looks fine to me. Might be better if enclosing the assigning expression in parentheses. Sure, if that pleases your eyes. --Max > > Xuelei > > On 7/20/2018 11:33 PM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8207223/webrev.00/ >> UNEXPECTED_MESSAGE indicates a flaw in the peer's protocol implementation, which should result in a SSLProtocolException. >> Thanks >> Max From chris.hegarty at oracle.com Mon Jul 23 10:09:16 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Jul 2018 11:09:16 +0100 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: <3c5c5465-492b-b740-77fc-f5a5c042d283@oracle.com> References: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> <1caeb924-26d2-14f6-9b0d-6f1cfc81a9ea@oracle.com> <0A75D4BE-B31B-4AD4-A526-25F32162062A@oracle.com> <3c5c5465-492b-b740-77fc-f5a5c042d283@oracle.com> Message-ID: Sean, > On 20 Jul 2018, at 18:07, Sean Mullan wrote: > > On 7/20/18 11:08 AM, Chris Hegarty wrote: >> This is ambiguous, and needs to be clarified. Surely, it is >> better to use the same wording as the serial filter: >> "Whitespace is significant and is considered part of the value." > > Kind of on the fence on that one. If this were a general property/value format, I would agree, but these values are fixed and not potentially complicated expressions. Sure, they are simple strings consisting of only printable characters. > For example, does this mean: > > jdk.includeInExceptions=hostInfo,jarInfo > > and > > jdk.includeInExceptions=hostInfo, jarInfo > > are different? And I assume the latter " jarInfo" would be ignored? > > If you are strongly in favor of this, I would highly recommend logging a warning when there is an unknown value, otherwise typos and such would be hard to detect (although this doesn't necessarily need to be in the specification). My original whitespace handling avoided the potential issue where a rogue lead or trailing whitespace accidentally found its way into a value, therefore avoiding the scenario above ( and potentially emitting a warning ). Whitespace is significant and should be specified as such, since ... jdk.includeInExceptions=?host Info? IS NOT equal to jdk.includeInExceptions=?hostInfo? and system property values can contain spaces jdk.includeInExceptions=?foo bar,hostInfo,jar Info,? After given this some more thought, I now think that I gave in to the comment to change whitespace handing too easy. While maybe not consistent, with the already inconsistent, whitespace handling in java.security, I think ( for this particular case ) the original - trim leading and trailing - is the right thing to do. It avoids your above scenario where someone accidentally adds a leading space, which could be difficult to debug/find without a warning - which we should avoid if possible. I?d like to re-propose the original webrev for consideration ( whitespace handling is the only change ): http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ -Chris. From chris.hegarty at oracle.com Mon Jul 23 11:02:30 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Jul 2018 12:02:30 +0100 Subject: Bug in HttpClient In-Reply-To: <27900b892ab06fad766652b87445450747bc1a8c.camel@redhat.com> References: <27900b892ab06fad766652b87445450747bc1a8c.camel@redhat.com> Message-ID: The following issue has been filed in JIRA to track the problem with an HTTP/1.0 response without a Content-Length header: https://bugs.openjdk.java.net/browse/JDK-8207966 -Chris. > On 20 Jul 2018, at 08:38, Severin Gehwolf wrote: > > Adding net-dev > > On Fri, 2018-07-20 at 08:52 +0200, Thomas Lu?nig wrote: >> Hi, >> i found an bug in JDK 10 with the new HttpClient. It does not handle >> responses wihtout contentlength correctly. >> Normally i would expect that the content is returned even without >> content length. Since i can not open an JDK bug >> i hope some person from the list can do it. Below is an example that >> show the problem. >> >> Gru? Thomas Lu?nig >> import java.io.InputStream; >> import java.io.OutputStream; >> import java.net.InetSocketAddress; >> import java.net.ServerSocket; >> import java.net.Socket; >> import java.net.URI; >> import java.time.Duration; >> import javax.net.ServerSocketFactory; >> import jdk.incubator.http.HttpClient; >> import jdk.incubator.http.HttpRequest; >> import jdk.incubator.http.HttpResponse; >> public class Client1 { >> static void server(final boolean withContentLength) { >> try(ServerSocket ss = >> ServerSocketFactory.getDefault().createServerSocket()) { >> ss.setReuseAddress(true); >> ss.bind(new InetSocketAddress("127.0.0.1",80)); >> final byte[] buf = new byte[120400]; >> try(Socket s = ss.accept()) { >> System.out.println("Accepted: >> "+s.getRemoteSocketAddress()); >> try( OutputStream os = >> s.getOutputStream(); InputStream is = s.getInputStream()) { >> is.read(buf); >> is.read(buf); >> os.write("HTTP/1.0 200 >> OK\r\nConnection: close\r\nContent-Type: text/xml; charset=UTF- >> 8\r\n".getBytes()); >> if(withContentLength) >> os.write("Content-Length: 4\r\n".getBytes()); >> os.write("\r\n".getBytes()); >> os.write("".getBytes()); >> os.flush(); >> } >> } >> } catch(final Throwable t) { t.printStackTrace(); } >> } >> static void client() { >> try { >> final HttpClient client = >> HttpClient.newBuilder().version(HttpClient.Version.HTTP_2).build(); >> final HttpResponse response = client >> .send(HttpRequest.newBuilder(new URI("htt >> p://127.0.0.1/test")).timeout(Duration.ofMillis(120_000)) >> >> .POST(HttpRequest.BodyPublisher.fromString("body")).build(), >> HttpResponse.BodyHandler.asString()); >> System.out.println("Received reply: " + >> response.statusCode()); >> System.out.println("Received body: " + >> response.body()); >> } catch(final Throwable t) { t.printStackTrace(); } >> } >> public static void main(final String[] args) throws Exception >> { >> new Thread(()->server(true)).start(); >> client(); >> new Thread(()->server(false)).start(); >> client(); >> } >> } From adam.petcher at oracle.com Mon Jul 23 14:22:17 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 23 Jul 2018 10:22:17 -0400 Subject: EC weirdness In-Reply-To: <979490f4-c208-1b9c-76ba-9aadf125fcac@comcast.net> References: <98f90517-33a5-5c62-3c2b-89c75967874e@oracle.com> <979490f4-c208-1b9c-76ba-9aadf125fcac@comcast.net> Message-ID: <96036b6d-c8bb-bb86-8abd-034207d21c60@oracle.com> On 7/19/2018 3:36 PM, Michael StJohns wrote: > On 7/16/2018 4:42 PM, Adam Petcher wrote: >> Though it has the additional benefit... > > Actually... >> The implementation may also need... > > Nope... I think that you interpreted my statements a bit more specifically that I intended. I was speaking in more general terms about ECC libraries in the JDK and elsewhere, because they are all motivated by the same forces. You may wan to read what I wrote again so you will more easily understand my position below. > > In the scheme, G' is secret.? This is basically the EC version of > https://en.wikipedia.org/wiki/SPEKE. > I may do a bit more archeology and see whether there are actual > dependencies on the build in curve data (e.g. PKCS11).? If not, I may > try and provide a patch refactoring out that limitation and doing a > more thorough separation of the math from the packaging. > I've been seeing a lot of interest in PAKE lately, so it may be worthwhile for us to do some work to support common PAKE schemes, especially if this support can be provided on top of existing DH implementations with small modifications. Though I think SPEKE can be implemented in other ways, and I'm still not convinced that this example provides enough motivation to support arbitrary base points. Here are some other approaches you may want to consider: 1) Use three-party Diffie-Hellman. You can view the password as some other party for whom nobody knows the private key, but authorized parties know the public key. I think this accomplishes the same thing, and I find it more agreeable than supporting arbitrary base points in KeyPairGenerator. In pseudocode: PublicKey passwordKey = Hash(password)... KeyPairGenerator kpg = ... KeyAgreement ka = ... KeyPair myPair = ka.generateKeyPair(); ka.init(myPair.getPrivate()); Key keyToBob = ka.doPhase(passwordKey, false); Key keyFromBob = exchangeWithBob(keyToBob); ka.doPhase(keyFromBob, true); byte[] sharedSecret = ka.generateSecret() Of course, you run into the problem that many DH implementations in the JDK only support two-party DH. You could start by seeing if this works with the "DiffieHellman" service. Adding support for multi-party DH would be trivial for X25519/X448, but may be harder for the older ECC implementation. 2) If you are willing to use the JDK 11 early access build, and use an internal API, then you can do what you want using X25519/X448 and the XECOperations class. It doesn't really allow arbitrary base points, but you can freely do scalar-point multiplications. I'm assuming this isn't what you want, but let me know if you want more details on how to use this class. 3) If there is sufficient demand for it (and someone who is willing to implement it), we might want to consider adding a crypto service for some standard PAKE scheme. From sean.mullan at oracle.com Mon Jul 23 15:58:41 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 23 Jul 2018 11:58:41 -0400 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: References: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> <1caeb924-26d2-14f6-9b0d-6f1cfc81a9ea@oracle.com> <0A75D4BE-B31B-4AD4-A526-25F32162062A@oracle.com> <3c5c5465-492b-b740-77fc-f5a5c042d283@oracle.com> Message-ID: <60a2405d-baae-9881-5872-cec0bca615d9@oracle.com> On 7/23/18 6:09 AM, Chris Hegarty wrote: > After given this some more thought, I now think that I gave in to the > comment to change whitespace handing too easy. While maybe not > consistent, with the already inconsistent, whitespace handling in > java.security, I think ( for this particular case ) the original - trim > leading and trailing - is the right thing to do. It avoids your above > scenario where someone accidentally adds a leading space, which could be > difficult to debug/find without a warning - which we should avoid if > possible. Thanks for making that change. > I?d like to re-propose the original webrev for consideration ( whitespace > handling is the only change ): > > http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ A few nits and wording suggestions in the java.security file: "By default, several exception messages do not include potentially sensitive information such as file names, host names, or port numbers." I think the following sounds a bit better: "By default, exception messages should not include potentially sensitive information such as file names, host names, or port numbers." Also, the 2nd and 3rd sentences basically say the same thing. I would remove the 2nd sentence. "The categories, to enable enhanced exception message information, are:" I would remove ", to enable enhanced exception message information," since it seems redundant (and I believe is grammatically incorrect). hostInfo - IOExceptions thrown by java.net.Socket and also the ... Remove "also" (not really necessary). --Sean From chris.hegarty at oracle.com Mon Jul 23 16:10:33 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Jul 2018 17:10:33 +0100 Subject: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property In-Reply-To: <60a2405d-baae-9881-5872-cec0bca615d9@oracle.com> References: <803E606C-CC41-47C4-9BD9-769208AAB5A9@oracle.com> <1caeb924-26d2-14f6-9b0d-6f1cfc81a9ea@oracle.com> <0A75D4BE-B31B-4AD4-A526-25F32162062A@oracle.com> <3c5c5465-492b-b740-77fc-f5a5c042d283@oracle.com> <60a2405d-baae-9881-5872-cec0bca615d9@oracle.com> Message-ID: Thanks for the review Sean, > On 23 Jul 2018, at 16:58, Sean Mullan wrote: > ... >> http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ > > A few nits and wording suggestions in the java.security file: > > "By default, several exception messages do not include potentially sensitive information such as file names, host names, or port numbers." > > I think the following sounds a bit better: > > "By default, exception messages should not include potentially sensitive > information such as file names, host names, or port numbers." > > Also, the 2nd and 3rd sentences basically say the same thing. I would remove the 2nd sentence. > > "The categories, to enable enhanced exception message information, are:" > > I would remove ", to enable enhanced exception message information," since it seems redundant (and I believe is grammatically incorrect). > > hostInfo - IOExceptions thrown by java.net.Socket and also the ... > > Remove "also" (not really necessary). Agreed. Here?s where this ended up. # # Enhanced exception message information # # By default, exception messages should not include potentially sensitive # information such as file names, host names, or port numbers. This property # accepts one or more comma separated values, each of which represents a # category of enhanced exception message information to enable. Values are # case-insensitive. Leading and trailing whitespaces, surrounding each value, # are ignored. Unknown values are ignored. # # The categories are: # # hostInfo - IOExceptions thrown by java.net.Socket and the socket types in the # java.nio.channels package will contain enhanced exception # message information # # The property setting in this file can be overridden by a system property of # the same name, with the same syntax and possible values. # #jdk.includeInExceptions=hostInfo -Chris From philippe.poulard at inria.fr Mon Jul 23 16:12:57 2018 From: philippe.poulard at inria.fr (Philippe Poulard) Date: Mon, 23 Jul 2018 18:12:57 +0200 (CEST) Subject: About Password security : new JEP needed ? Message-ID: <426418023.13765285.1532362377454.JavaMail.zimbra@inria.fr> Dear security experts, I would like to hear you about a security flaw still present in Java, and whether it is worth to submit a new feature (JEP) or not. It is about how passwords are managed in the memory. Actually, Meltdown and Spectre show us recently how much it is important to limit the risk of accessing passwords that live in the memory, because unfortunately Java doesn't prevent leaking passwords all along classicals processing chains. Leaking, in the sense that the data are not explicitely erased from the memory after using them. Here is a scenario of how a password is taken in charge by a typical Web application : 0) a user is asked to login, and send its credentials to the server with HTTPS (not our concern, it is just the start of the story) 1) the Web server decodes the HTTP request and retrieve the login/password 2) it computes a crypt of the password (alternatively, it can ask a remote service to check it, such as an LDAP server to do it ; but let's stay in the same JVM) 3) the access to the expected resource is granted (or not) to the authentified (or not) user The JVM let lots of traces here and there : 1) Inside the Web server : what is annoying here is that whithin every Java Web server, since we are relying on HTTP and that HTTP is text, this text is available only in the form of Strings (and if you perform a BASIC AUTH, the password will be processed as text ; if you have a registration form, the password POST params will be processed as text), and we all know that a String is immutable ; when dropped, the clear password will live in the memory before being reclaimed by the GC and reallocated. Curiously, the crypto specification states that since Strings are immutable, char arrays are preferred for storing passwords ; this is exactly what happenned with the legacy swing JPasswordField (within which the password is given as a char array), but that was completely missed in servlets. I propose to fix this by : 1a) changing how passwords are exposed to the users in Java (not only in webapps) : a Password class that ensure to erase the chars after using them, and in the meantime to hide them properly (see below), 1b) and change the servlet specification accordingly in order to forbid using String for passwords (see below). 2) Computing a crypt : first, the password must be converted to bytes, then processed by a hash algorithm. 2a) About char encoding : first, if we have a close look on how the password characters are encoded to bytes, this is performed with the help of java.nio.ByteBuffer, CharBuffer, java.nio.charset.Charset, CharsetEncoder. A charset encoder will allocate an average amount of memory for the byte buffer, but this may not be the right size, which cause to reallocate a new array ; the previous array is just dropped and will be reclaimed (one day) by the GC, but in the meantime, partial data are still alive in the memory. I propose to fix this with a SafeBuffer class that cleans intermediate sensible data when they are no longer in use (buffer underflow/overflow) (see below). 2b) Hashing : nowaday, computing a crypt from a password consists on applying a hash function on the password and repeat so that it will take -say- 100 ms. 100 ms is a very very long time in CPU time, and unfortunately the password bytes are still clear in the memory during this time (this is the case for PBKDF2 and BCrypt if you look at the algorithms). Inside a Web server where several simultaneous logins are attempted by different users, the chance for an attacker to capture a password is significantly increased. PBKDF2 and BCrypt are using the input password at each loop, making the password exposed in clear during all the hashing process. Conversely, Argon2 first prehash the password, then drop it, and use the prehash password during the loop. BCrypt-with-SHA2 (not sure if this variant is available in the Java platform, maybe supply by a provider, but it exists in a Python security library) also prehash the password with SHA2, which makes it better than BCrypt alone. I propose just to promote algorithms (like Argon2 and BCrypt-with-SHA2) that are prehashing the password before the big loop, since they avoid to hold the password in clear. Details of the proposals and implementation : Note that things are subject to evolve according to your feedbacks ; the packages are my own, but could be moved to some Java namespace if a JDK integration would become relevant. 1a) How passwords are exposed to the users : we could let the user deal with char[], but are we sure that he will erase properly the sensitive data ? I suggest a wrapper like this : https://github.com/alternet/alternet.ml/blob/master/security/src/main/java/ml/alternet/security/Password.java that ensure to clear data after using them. Usage : http://alternet.ml/alternet-libs/security/security.html#passwords Additionally, while the password is not in use, it is encrypted inside this class. Encryption doesn't prevent an attacker to retrieve the bytes, retrieve the algorithm, and retrieve the key, but all that informations are not clear in the memory, and it is harder to get back the clear password than letting it as-is in the memory. Advanced usage could consider to store the encryption key outside the current JVM / machine, but I didn't implement such solution. Other helper classes are available : https://github.com/alternet/alternet.ml/tree/master/security/src/main/java/ml/alternet/security 1b) How passwords are exposed in servlets : the idea is to capture the bytes before they are processed by the Web server, and if they appear to be passwords, to encrypt them in the safe Password class, and to clean the memory where they come from. I didn't patch the servlet API right now, but it would be relevant to have inside javax.servlet.ServletRequest a new method like this : List getPasswords(String fields...); // FORM auth http://alternet.ml/alternet-libs/security/security.html#webapps Right now, as a proof of concept, I have agnostic bindings for Servlets and REST (JAX-RS) for FORM auth and BASIC auth (or FORMs that contain passwords, such as a "new user registration"): https://github.com/alternet/alternet.ml/tree/master/security/src/main/java/ml/alternet/security/web and implementations for Tomcat : https://github.com/alternet/alternet.ml/tree/master/security-tomcat-8.0/src/main/java/ml/alternet/security/web/tomcat and Jetty : https://github.com/alternet/alternet.ml/tree/master/security-jetty-9.1/src/main/java/ml/alternet/security/web/jetty (Tomcat and Jetty hacks are just for demonstration, they certainly need a deeper integration, but I have a full example webapp with LDAP auth that works well, and full test scenarios that show various usage examples) 2a) Decoding bytes to characters without leaking : just a class that takes care of the data created, and that ensure to erase them. Here is an example of implementation : https://github.com/alternet/alternet.ml/blob/master/security-auth/src/main/java/ml/alternet/security/binary/SafeBuffer.java You will find in the following project detailed informations and a complete test-suite that ensure that everything works properly : http://alternet.ml/alternet-libs/security/security.html Additionally, there is an auth framework that use that Password class and ensure to clean properly sensitive data when hashing. All those considerations are not big security issues (do little security issues exist ?), but do you think they ought to be taken into account in a new proposal (JEP) ? Best Regards, Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Jul 23 22:18:58 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 23 Jul 2018 15:18:58 -0700 Subject: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found In-Reply-To: <905d69d6-1112-0b53-9124-f53c783fa803@oracle.com> References: <905d69d6-1112-0b53-9124-f53c783fa803@oracle.com> Message-ID: <177a4bf1-da82-4b70-abad-6ac794fea9e6@oracle.com> Hi John, Changes look fine. I just have one nit, perhaps add more information reporting when skipping tests, e.g. PKCS11Test: line 163, TestNssDbSqlite.java: line 68. Thanks, Valerie On 7/9/2018 12:38 AM, sha.jiang at oracle.com wrote: > Hi Thomas, > Thanks for your testing. > > I'm not sure that's a reasonable case. > From my view, PKCS11Test.java simply checks if the NSS library > directory exists. > But it looks unnecessary to check every library file. > In fact, if removing libnss3 or libsoftokn3's dependencies, like > libnssutil3, the test also fails. > > However, I still re-checked my previous solution, and made a new > webrev [1]. > The constant badNSSVersion in PKCS11Test.java may not be fine. > The static field nss_library in PKCS11Test.java can be softokn3 or > nss3 for different tests. > badNSSVersion should be checked after the target nss library is > determined. > And this checking should happen before the real testing, especially > before security manager is enabled. > So, a new extension method, exactly PKCS11Test::skipTest, was > introduced, and the affected tests were modified accordingly. > > [1] http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ > > Best regards, > John Jiang > > On 2018/7/4 14:15, Thomas St?fe wrote: >> Hi, >> >> Unfortunately this is not enough. >> >> Running tests with your patch and NSS libs disabled (I renamed >> libsoftokn3.so) yields the following errors: >> >> sun/security/pkcs11/Secmod/AddPrivateKey.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/AddTrustedCert.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/Crypto.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/GetPrivateKey.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/JksSetPrivateKey.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/LoadKeystore.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/TestNssDbSqlite.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> sun/security/pkcs11/Secmod/TrustAnchors.java >> ????????????????????????????????????????????????? Failed. Execution >> failed: `main' threw exception: java.security.ProviderException: Could >> not initialize NSS >> >> >> Excerpt from TestNssDbSqlite.jtr: >> >> ----------messages:(3/98)---------- >> command: build TestNssDbSqlite >> reason: Named class compiled on demand >> elapsed time (seconds): 0.0 >> result: Passed. All files up to date >> >> #section:main >> ----------messages:(5/721)---------- >> command: main TestNssDbSqlite >> reason: User specified action: run main/othervm/timeout=120 >> TestNssDbSqlite >> Mode: othervm [/othervm specified] >> Additional options from @modules: --add-modules >> java.base,jdk.crypto.cryptoki --add-exports >> java.base/sun.security.rsa=ALL-UNNAMED --add-exports >> java.base/sun.security.provider=ALL-UNNAMED --add-exports >> java.base/sun.security.jca=ALL-UNNAMED --add-exports >> java.base/sun.security.tools.keytool=ALL-UNNAMED --add-exports >> java.base/sun.security.x509=ALL-UNNAMED --add-exports >> java.base/com.sun.crypto.provider=ALL-UNNAMED --add-exports >> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED --add-opens >> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED >> elapsed time (seconds): 0.445 >> ----------configuration:(11/604)---------- >> Boot Layer >> ?? add modules: java.base jdk.crypto.cryptoki >> ?? add exports: java.base/com.sun.crypto.provider ALL-UNNAMED >> ??????????????? java.base/sun.security.jca ALL-UNNAMED >> ??????????????? java.base/sun.security.provider ALL-UNNAMED >> ??????????????? java.base/sun.security.rsa ALL-UNNAMED >> ??????????????? java.base/sun.security.tools.keytool ALL-UNNAMED >> ??????????????? java.base/sun.security.x509 ALL-UNNAMED >> ??????????????? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >> ?? add opens:?? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >> >> ----------System.out:(1/64)---------- >> Warning: can't find NSS librarys on this machine, skipping test >> ----------System.err:(25/1633)---------- >> java.security.ProviderException: Could not initialize NSS >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:218) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) >> at PKCS11Test.getSunPKCS11(PKCS11Test.java:152) >> at TestNssDbSqlite.initializeProvider(TestNssDbSqlite.java:121) >> at TestNssDbSqlite.initialize(TestNssDbSqlite.java:112) >> at TestNssDbSqlite.main(TestNssDbSqlite.java:67) >> 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:115) >> at java.base/java.lang.Thread.run(Thread.java:834) >> Caused by: java.io.IOException: NSS initialization failed >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:234) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:213) >> ... 14 more >> >> Kind Regards, Thomas >> >> >> On Wed, Jul 4, 2018 at 7:36 AM,? wrote: >>> Hi, >>> If NSS libs are unavailable, PKCS11 tests fail when checking NSS >>> version. >>> This patch tries to fix this issue. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206258 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.00/ >>> >>> Best regards, >>> John Jiang >>> > From mbalao at redhat.com Tue Jul 24 04:50:57 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 24 Jul 2018 01:50:57 -0300 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Message-ID: Hi Valerie, Webrev 05: * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.05/ * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.05.zip New in Webrev 05: * Explicitly casted prfHashMechanism to CK_MECHANISM_TYPE type to avoid building warning on some compilers (it's a long -> unsigned long cast). Regression tests result for jdk/sun/security/pkcs11 category: Passed: sun/security/pkcs11/Cipher/JNICheck.java Passed: sun/security/pkcs11/Cipher/ReinitCipher.java Passed: sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java Passed: sun/security/pkcs11/Cipher/TestRawRSACipher.java Passed: sun/security/pkcs11/Cipher/TestRSACipher.java Passed: sun/security/pkcs11/Cipher/TestRSACipherWrap.java Passed: sun/security/pkcs11/Cipher/TestSymmCiphers.java Passed: sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java Passed: sun/security/pkcs11/Config/ReadConfInUTF16Env.sh Passed: sun/security/pkcs11/ec/ReadCertificates.java Passed: sun/security/pkcs11/ec/ReadPKCS12.java Passed: sun/security/pkcs11/ec/TestCurves.java Passed: sun/security/pkcs11/ec/TestECDH.java Passed: sun/security/pkcs11/ec/TestECDH2.java Passed: sun/security/pkcs11/ec/TestECDSA.java Passed: sun/security/pkcs11/ec/TestECDSA2.java Passed: sun/security/pkcs11/ec/TestECGenSpec.java FAILED: sun/security/pkcs11/ec/TestKeyFactory.java Passed: sun/security/pkcs11/fips/ClientJSSEServerJSSE.java Passed: sun/security/pkcs11/fips/TrustManagerTest.java Passed: sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java Passed: sun/security/pkcs11/KeyAgreement/TestDH.java Passed: sun/security/pkcs11/KeyAgreement/TestInterop.java Passed: sun/security/pkcs11/KeyAgreement/TestShort.java Passed: sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java Passed: sun/security/pkcs11/KeyGenerator/DESParity.java Passed: sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java Passed: sun/security/pkcs11/KeyPairGenerator/TestDH2048.java Passed: sun/security/pkcs11/KeyStore/Basic.sh Passed: sun/security/pkcs11/KeyStore/ClientAuth.sh Passed: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh Passed: sun/security/pkcs11/KeyStore/Solaris.sh Passed: sun/security/pkcs11/Mac/MacKAT.java Passed: sun/security/pkcs11/Mac/MacSameTest.java Passed: sun/security/pkcs11/Mac/ReinitMac.java Passed: sun/security/pkcs11/MessageDigest/ByteBuffers.java Passed: sun/security/pkcs11/MessageDigest/DigestKAT.java Passed: sun/security/pkcs11/MessageDigest/ReinitDigest.java Passed: sun/security/pkcs11/MessageDigest/TestCloning.java Passed: sun/security/pkcs11/Provider/Absolute.java Passed: sun/security/pkcs11/Provider/ConfigQuotedString.sh Passed: sun/security/pkcs11/Provider/ConfigShortPath.java Passed: sun/security/pkcs11/Provider/Login.sh Passed: sun/security/pkcs11/Provider/LoginISE.java Passed: sun/security/pkcs11/rsa/KeyWrap.java Passed: sun/security/pkcs11/rsa/TestCACerts.java Passed: sun/security/pkcs11/rsa/TestKeyFactory.java Passed: sun/security/pkcs11/rsa/TestKeyPairGenerator.java Passed: sun/security/pkcs11/rsa/TestSignatures.java Passed: sun/security/pkcs11/Secmod/AddPrivateKey.java FAILED: sun/security/pkcs11/Secmod/AddTrustedCert.java Passed: sun/security/pkcs11/Secmod/Crypto.java Passed: sun/security/pkcs11/Secmod/GetPrivateKey.java Passed: sun/security/pkcs11/Secmod/JksSetPrivateKey.java Passed: sun/security/pkcs11/Secmod/LoadKeystore.java Passed: sun/security/pkcs11/Secmod/TestNssDbSqlite.java Passed: sun/security/pkcs11/Secmod/TrustAnchors.java Passed: sun/security/pkcs11/SecureRandom/Basic.java Passed: sun/security/pkcs11/SecureRandom/TestDeserialization.java Passed: sun/security/pkcs11/Serialize/SerializeProvider.java Passed: sun/security/pkcs11/Signature/ByteBuffers.java Passed: sun/security/pkcs11/Signature/ReinitSignature.java Passed: sun/security/pkcs11/Signature/TestDSA.java Passed: sun/security/pkcs11/Signature/TestDSAKeyLength.java Passed: sun/security/pkcs11/Signature/TestRSAKeyLength.java Passed: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java FAILED: sun/security/pkcs11/tls/TestKeyMaterial.java Passed: sun/security/pkcs11/tls/TestLeadingZeroesP11.java Passed: sun/security/pkcs11/tls/TestMasterSecret.java Passed: sun/security/pkcs11/tls/TestPremaster.java Passed: sun/security/pkcs11/tls/TestPRF.java Passed: sun/security/pkcs11/tls/TestTLS12.java Passed: sun/security/pkcs11/SampleTest.java Test results: passed: 70; failed: 3 NOTE: failing testcases were already failing on an unpatched JDK. Look forward to your answer. Kind regards, Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Tue Jul 24 06:10:26 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 24 Jul 2018 14:10:26 +0800 Subject: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found In-Reply-To: <177a4bf1-da82-4b70-abad-6ac794fea9e6@oracle.com> References: <905d69d6-1112-0b53-9124-f53c783fa803@oracle.com> <177a4bf1-da82-4b70-abad-6ac794fea9e6@oracle.com> Message-ID: <95234233-a35f-8a48-7f22-73f058524601@oracle.com> Hi Valerie, Thanks for your review! Please take a look at this new webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.02 On 2018/7/24 06:18, Valerie Peng wrote: > Hi John, > > Changes look fine. > > I just have one nit, perhaps add more information reporting when > skipping tests, e.g. > > PKCS11Test: line 163 Different tests may have different reasons for skipping testing. So, it would be better to output the info in PKCS11Test's child classes. In fact, the tests overriding the method PKCS11Test::skipTest already report the reasons respectively. > TestNssDbSqlite.java: line 68. Add the below line 120???????????? System.out.println("Cannot init security module database, skipping"); Best regards, John Jiang > > Thanks, > Valerie > > On 7/9/2018 12:38 AM, sha.jiang at oracle.com wrote: >> Hi Thomas, >> Thanks for your testing. >> >> I'm not sure that's a reasonable case. >> From my view, PKCS11Test.java simply checks if the NSS library >> directory exists. >> But it looks unnecessary to check every library file. >> In fact, if removing libnss3 or libsoftokn3's dependencies, like >> libnssutil3, the test also fails. >> >> However, I still re-checked my previous solution, and made a new >> webrev [1]. >> The constant badNSSVersion in PKCS11Test.java may not be fine. >> The static field nss_library in PKCS11Test.java can be softokn3 or >> nss3 for different tests. >> badNSSVersion should be checked after the target nss library is >> determined. >> And this checking should happen before the real testing, especially >> before security manager is enabled. >> So, a new extension method, exactly PKCS11Test::skipTest, was >> introduced, and the affected tests were modified accordingly. >> >> [1] http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ >> >> Best regards, >> John Jiang >> >> On 2018/7/4 14:15, Thomas St?fe wrote: >>> Hi, >>> >>> Unfortunately this is not enough. >>> >>> Running tests with your patch and NSS libs disabled (I renamed >>> libsoftokn3.so) yields the following errors: >>> >>> sun/security/pkcs11/Secmod/AddPrivateKey.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/AddTrustedCert.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/Crypto.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/GetPrivateKey.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/JksSetPrivateKey.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/LoadKeystore.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/TestNssDbSqlite.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> sun/security/pkcs11/Secmod/TrustAnchors.java >>> ????????????????????????????????????????????????? Failed. Execution >>> failed: `main' threw exception: java.security.ProviderException: Could >>> not initialize NSS >>> >>> >>> Excerpt from TestNssDbSqlite.jtr: >>> >>> ----------messages:(3/98)---------- >>> command: build TestNssDbSqlite >>> reason: Named class compiled on demand >>> elapsed time (seconds): 0.0 >>> result: Passed. All files up to date >>> >>> #section:main >>> ----------messages:(5/721)---------- >>> command: main TestNssDbSqlite >>> reason: User specified action: run main/othervm/timeout=120 >>> TestNssDbSqlite >>> Mode: othervm [/othervm specified] >>> Additional options from @modules: --add-modules >>> java.base,jdk.crypto.cryptoki --add-exports >>> java.base/sun.security.rsa=ALL-UNNAMED --add-exports >>> java.base/sun.security.provider=ALL-UNNAMED --add-exports >>> java.base/sun.security.jca=ALL-UNNAMED --add-exports >>> java.base/sun.security.tools.keytool=ALL-UNNAMED --add-exports >>> java.base/sun.security.x509=ALL-UNNAMED --add-exports >>> java.base/com.sun.crypto.provider=ALL-UNNAMED --add-exports >>> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED --add-opens >>> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED >>> elapsed time (seconds): 0.445 >>> ----------configuration:(11/604)---------- >>> Boot Layer >>> ?? add modules: java.base jdk.crypto.cryptoki >>> ?? add exports: java.base/com.sun.crypto.provider ALL-UNNAMED >>> ??????????????? java.base/sun.security.jca ALL-UNNAMED >>> ??????????????? java.base/sun.security.provider ALL-UNNAMED >>> ??????????????? java.base/sun.security.rsa ALL-UNNAMED >>> ??????????????? java.base/sun.security.tools.keytool ALL-UNNAMED >>> ??????????????? java.base/sun.security.x509 ALL-UNNAMED >>> ??????????????? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >>> ?? add opens:?? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >>> >>> ----------System.out:(1/64)---------- >>> Warning: can't find NSS librarys on this machine, skipping test >>> ----------System.err:(25/1633)---------- >>> java.security.ProviderException: Could not initialize NSS >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:218) >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) >>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) >>> at PKCS11Test.getSunPKCS11(PKCS11Test.java:152) >>> at TestNssDbSqlite.initializeProvider(TestNssDbSqlite.java:121) >>> at TestNssDbSqlite.initialize(TestNssDbSqlite.java:112) >>> at TestNssDbSqlite.main(TestNssDbSqlite.java:67) >>> 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:115) >>> at java.base/java.lang.Thread.run(Thread.java:834) >>> Caused by: java.io.IOException: NSS initialization failed >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:234) >>> at >>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:213) >>> ... 14 more >>> >>> Kind Regards, Thomas >>> >>> >>> On Wed, Jul 4, 2018 at 7:36 AM,? wrote: >>>> Hi, >>>> If NSS libs are unavailable, PKCS11 tests fail when checking NSS >>>> version. >>>> This patch tries to fix this issue. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206258 >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.00/ >>>> >>>> Best regards, >>>> John Jiang >>>> >> > > From weijun.wang at oracle.com Tue Jul 24 10:49:12 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 24 Jul 2018 18:49:12 +0800 Subject: RFR 8076190: Support passwordless access to PKCS12 keystores Message-ID: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> Please review the code change and CSR at webrev: http://cr.openjdk.java.net/~weijun/8076190/webrev.01/ CSR: https://bugs.openjdk.java.net/browse/JDK-8202590 The bug is at https://bugs.openjdk.java.net/browse/JDK-8076190 This is the 1st part of the process to make cacerts using pkcs12: 1. Support passwordless access to PKCS12 keystores 2. Update default algorithms and params when creating a PKCS12 keystore 3. Update keytool to support passwordless pkcs12 keystores 4. Migrate cacerts to pkcs12 Thanks Max From bradford.wetmore at oracle.com Tue Jul 24 23:59:30 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 24 Jul 2018 16:59:30 -0700 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <19470b78-d52e-b476-d879-6959760c4f6a@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> <19470b78-d52e-b476-d879-6959760c4f6a@oracle.com> Message-ID: <8601c0bb-0f73-76d6-8ad0-5f8dd3e788e0@oracle.com> Returning to this briefly, looks good to me too. Brad On 7/19/2018 6:23 PM, Valerie Peng wrote: > Thanks Max and Sean for the review and suggestions. I have updated the > webrev accordingly and finalized CSR. > > Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.04/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 > > Valerie > > On 7/19/2018 3:13 PM, Wang Weijun wrote: >> >>> ? 2018?7?20??05:18?Valerie Peng ??? >>> >>> Hi Sean, >>> >>> Thanks for the suggestion, I like it. >> Me too. >> >>> Max, any objection or concern before I update the webrev and CSR? >> No. >> >> Thanks >> Max >> >>> Valerie >>> >>> >>>> On 7/19/2018 7:28 AM, Sean Mullan wrote: >>>> Hi Valerie, Max - >>>> >>>> I took a fresh look at this issue this morning. I think we are >>>> getting bogged down by trying to adjust within the current wording, >>>> which is somewhat awkward and hard to understand. So, I think it >>>> might be better to break up the wording into multiple sentences. >>>> Here's a cut at the rewording: >>>> >>>> /** >>>> ? * Returns the parameters used with this signature object. >>>> ? * >>>> ? *

If this signature has been previously initialized with >>>> parameters >>>> ? * (by calling the {@code setParameter} method), this method returns >>>> ? * the same parameters. If this signature has not been initialized >>>> with >>>> ? * parameters, this method may return a combination of default and >>>> ? * randomly generated parameter values if the underlying >>>> ? * signature implementation supports it and can successfully generate >>>> ? * them. Otherwise, {@code null} is returned. >>>> ? * >>>> ? * @return the parameters used with this signature, or {@code null} >>>> ? */ >>>> >>>> In the first sentence of the 2nd paragraph above, I wanted to first >>>> list the case where the signature is initialized with parameters, >>>> which is the most clear-cut case of what the behavior will be. Then >>>> I described the case where an implementation may return >>>> default/generated parameters -- and this is clearly marked "may" >>>> since it is optional. All other cases other than those two always >>>> return null, so I think this makes it easier to understand. >>>> >>>> --Sean >>>> >>>>> On 7/18/18 1:29 PM, Valerie Peng wrote: >>>>> Sean, >>>>> >>>>> Where do you think that we should add the part about "null must be >>>>> returned ..." paragraph? At the end of first or second paragraph? >>>>> >>>>> I will go with majority. >>>>> >>>>> Valerie >>>>> >>>>>> On 7/17/2018 8:38 PM, Weijun Wang wrote: >>>>>> Is it better to append the new lines to the 2nd paragraph? >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Jul 18, 2018, at 9:46 AM, Valerie Peng >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Ok, let's use "must" then. I have also added the part about >>>>>>> default parameters. >>>>>>> Hope that all is clear now. >>>>>>> >>>>>>> Latest webrev: >>>>>>> http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/ >>>>>>> Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> On 7/17/2018 5:50 PM, Weijun Wang wrote: >>>>>>>>> On Jul 18, 2018, at 8:23 AM, Valerie Peng >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> Thanks for the suggestions. Please find comments inline. >>>>>>>>> >>>>>>>>>> On 7/16/2018 7:38 PM, Weijun Wang wrote: >>>>>>>>>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >>>>>>>>>> >>>>>>>>>> - At the end of the 1st paragraph, you have now >>>>>>>>>> >>>>>>>>>>> ??? However, for signature algorithm such as "RSASSA-PSS", it >>>>>>>>>>> requires parameters and the one used for signing must be >>>>>>>>>>> supplied for verification to succeed. It may be better to >>>>>>>>>>> return null instead of returning provider-specific default >>>>>>>>>>> parameters. >>>>>>>>>> I suggest we don't talk about the reason (params must be the >>>>>>>>>> same for signing and verification), we can just say something >>>>>>>>>> like "If there is no provider-specific default parameters, >>>>>>>>>> this method should return null before user sets one". >>>>>>>>> Alright, I initially didn't put down the reason. But since Brad >>>>>>>>> asked about it, I add it to the CSR in case Joe raise the same >>>>>>>>> question. I will update the CSR per your suggestion. >>>>>>>>>> - null may be returned >>>>>>>>>> >>>>>>>>>> How about "{@code null} must be returned"? >>>>>>>>> How about "should"? Is there a guideline on when to use >>>>>>>>> "may/should/must"? Anyone knows? >>>>>>>> Even if there were guidelines on this for Java, I think we >>>>>>>> should just stick to https://tools.ietf.org/html/rfc2119, except >>>>>>>> that the capitalization is not necessary. >>>>>>>> >>>>>>>> "Must" is precise here. >>>>>>>> >>>>>>>>> I thought must is mostly used in mandating input arguments must >>>>>>>>> not be null. But don't recall it being used much for return >>>>>>>>> values. >>>>>>>> "must return" appears 39 times in java/ and "should return" 19 >>>>>>>> (simple grep, no line break). >>>>>>>> >>>>>>>> --Max >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>>> Everything else looks fine. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>>> On Jul 17, 2018, at 9:46 AM, Valerie Peng >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> Good catch on the SignatureSpi class and SunMSCAPI provider, >>>>>>>>>>> I will include them. >>>>>>>>>>> >>>>>>>>>>> As for the part about "randomly generated", I am leaning >>>>>>>>>>> toward not having it as I don't see? a value of specifying this. >>>>>>>>>>> >>>>>>>>>>> Webrev and CSR has been updated. >>>>>>>>>>> >>>>>>>>>>> New webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>>>>>>>>>> Valerie >>>>>>>>>>>> >>>>>>>>>>>> Would you like to retain the word "randomly generated" >>>>>>>>>>>> somewhere? >>>>>>>>>>>> >>>>>>>>>>>> Also, the SignatureSpi class needs to be updated in the same >>>>>>>>>>>> way. >>>>>>>>>>>> >>>>>>>>>>>> Can you also update the implementation in the MSCAPI >>>>>>>>>>>> Signature object? >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> No issues found and it seems ok to return null if no >>>>>>>>>>>>> parameters is set. Thus, I have updated the webrev and CSR >>>>>>>>>>>>> accordingly. >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Valerie >>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>>>>>>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>>>>>>>>>> I will explore it more and see. >>>>>>>>>>>>>> Thanks for the feedback, >>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>>>>>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>>>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The javadoc is for Signature.getParameters(), so null >>>>>>>>>>>>>>>>> can be returned for signature algorithms which do not >>>>>>>>>>>>>>>>> use parameters, e.g. SHA256withDSA. As Signature class >>>>>>>>>>>>>>>>> covers all signature algorithms, I am not sure about >>>>>>>>>>>>>>>>> mentioning specific algorithm names as it may be >>>>>>>>>>>>>>>>> lengthy and even misleading unless we list out all >>>>>>>>>>>>>>>>> applicable algorithms. >>>>>>>>>>>>>>>> Sure. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The part of "default and randomly generated" is >>>>>>>>>>>>>>>>> inherited from existing javadoc. I think "default" in >>>>>>>>>>>>>>>>> the aforementioned sentence means "hardcoded values". >>>>>>>>>>>>>>>>> For example, something like salt length will likely >>>>>>>>>>>>>>>>> have a fixed default value. Since we have no control >>>>>>>>>>>>>>>>> over 3rd party providers, I think we may have to keep >>>>>>>>>>>>>>>>> this for backward compatibility reason. For RSASSA-PSS >>>>>>>>>>>>>>>>> sig algorithm, it errors out if the required parameter >>>>>>>>>>>>>>>>> is not given. Thus, I added the sentence "If there are >>>>>>>>>>>>>>>>> no provider-specific default values, the underlying >>>>>>>>>>>>>>>>> signature implementation may also fail". >>>>>>>>>>>>>>>> OK, now I understand "a combination of default and >>>>>>>>>>>>>>>> randomly generated" means some part of the parameter is >>>>>>>>>>>>>>>> hardcoded and some is random. Anyway, let's keep it >>>>>>>>>>>>>>>> unchanged. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Then, how about simply "If there are no >>>>>>>>>>>>>>>> provider-specific values" which covers both hardcoded >>>>>>>>>>>>>>>> and random values? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "the underlying signature implementation may also fail" >>>>>>>>>>>>>>>> is still not clear to me. If I had not read the CSR I >>>>>>>>>>>>>>>> would thought an exception will be thrown when >>>>>>>>>>>>>>>> update/sign is called. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As for @throws, I debated about it. The main reason for >>>>>>>>>>>>>>>>> not adding one is consistency. Many (or should I say >>>>>>>>>>>>>>>>> most) security classes do not have @throws for >>>>>>>>>>>>>>>>> ProviderException. If we were to add @throws >>>>>>>>>>>>>>>>> ProviderException here, we should do it across the >>>>>>>>>>>>>>>>> board. Besides, it is recommended to NOT document >>>>>>>>>>>>>>>>> runtime exceptions which callers are not prepared to >>>>>>>>>>>>>>>>> handle. >>>>>>>>>>>>>>>> I assume other getParameters() had not added it is >>>>>>>>>>>>>>>> because it happened they can return one. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> While people does not catch runtime exceptions but my >>>>>>>>>>>>>>>> understanding is that if you mentioned "fail" in the >>>>>>>>>>>>>>>> spec maybe it's better to add a @throws for it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For example, @throws SecurityException for File/Files >>>>>>>>>>>>>>>> operations. >>>>>>>>>>>>>>> Thinking more about this, I would be more inclined to >>>>>>>>>>>>>>> recommend that you change the meaning of null as the >>>>>>>>>>>>>>> return value to cover both cases: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @return the parameters used with this signature, or null >>>>>>>>>>>>>>> if this signature does not use any parameters or does not >>>>>>>>>>>>>>> support default or randomly generated parameter values >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't think it is critical to make a distinction >>>>>>>>>>>>>>> between these 2 cases, because if the programmer doesn't >>>>>>>>>>>>>>> initialize it with parameters it will get a >>>>>>>>>>>>>>> SignatureException anyway when it tries to call sign or >>>>>>>>>>>>>>> verify. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It's not perfect, but probably the best you can do >>>>>>>>>>>>>>> working within the constraints of that API and minimizing >>>>>>>>>>>>>>> compatibility risk. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --Sean >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>>>>>>>>>> Hi Valerie >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> About "it *may* return", do you mean it could also >>>>>>>>>>>>>>>>>> return null? My understanding is no. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is it better to clarify when the implementation "may >>>>>>>>>>>>>>>>>> also fail"? From the CSR, it's this method. Can you >>>>>>>>>>>>>>>>>> add a @throws spec to this method then? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Also, I am a little confused by "default and randomly >>>>>>>>>>>>>>>>>> generated". Does this actually mean "default (might be >>>>>>>>>>>>>>>>>> randomly generated)"? The "it may" sentence mentions >>>>>>>>>>>>>>>>>> "default and randomly generated" but the "if there" >>>>>>>>>>>>>>>>>> only says "default", which sounds like the the >>>>>>>>>>>>>>>>>> "randomly generated" case could be different. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Brad, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Would you have time to review the fix for >>>>>>>>>>>>>>>>>>> JDK-8206171: Signature#getParameters for RSASSA-PSS >>>>>>>>>>>>>>>>>>> throws ProviderException when not initialized? >>>>>>>>>>>>>>>>>>> No source code changes, but just updating javadoc to >>>>>>>>>>>>>>>>>>> mention the possible failure case. >>>>>>>>>>>>>>>>>>> Otherwise, JCK team expects a parameter object or >>>>>>>>>>>>>>>>>>> null being returned. >>>>>>>>>>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > From weijun.wang at oracle.com Wed Jul 25 01:38:49 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 25 Jul 2018 09:38:49 +0800 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <8601c0bb-0f73-76d6-8ad0-5f8dd3e788e0@oracle.com> References: <9143dd7b-fa01-6ae5-9c45-7d63ea6c8680@oracle.com> <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> <19470b78-d52e-b476-d879-6959760c4f6a@oracle.com> <8601c0bb-0f73-76d6-8ad0-5f8dd3e788e0@oracle.com> Message-ID: <68B87EA5-6F86-4970-AB80-556D4783CF28@oracle.com> Something related. Cipher has a similar init(..,params) and getParameters() structure and the spec is also similar. *

The returned parameters may be the same that were used to initialize * this cipher, or may contain a combination of default and random * parameter values used by the underlying cipher implementation if this * cipher requires algorithm parameters but was not initialized with any. However, one can supply an incomplete parameters object in init() and getParameters() will fill in default/random values to make it complete. For example, in PBE-based Cipher, one can only include salt and iteration count in the init params, and init() will add in a random IV, and the IV can be retrieved with getParameters(). Is this something we need to clarify? Thanks Max > On Jul 25, 2018, at 7:59 AM, Bradford Wetmore wrote: > > Returning to this briefly, looks good to me too. > > Brad > > > > On 7/19/2018 6:23 PM, Valerie Peng wrote: >> Thanks Max and Sean for the review and suggestions. I have updated the webrev accordingly and finalized CSR. >> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.04/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >> Valerie >> On 7/19/2018 3:13 PM, Wang Weijun wrote: >>> >>>> ? 2018?7?20??05:18?Valerie Peng ??? >>>> >>>> Hi Sean, >>>> >>>> Thanks for the suggestion, I like it. >>> Me too. >>> >>>> Max, any objection or concern before I update the webrev and CSR? >>> No. >>> >>> Thanks >>> Max >>> >>>> Valerie >>>> >>>> >>>>> On 7/19/2018 7:28 AM, Sean Mullan wrote: >>>>> Hi Valerie, Max - >>>>> >>>>> I took a fresh look at this issue this morning. I think we are getting bogged down by trying to adjust within the current wording, which is somewhat awkward and hard to understand. So, I think it might be better to break up the wording into multiple sentences. Here's a cut at the rewording: >>>>> >>>>> /** >>>>> * Returns the parameters used with this signature object. >>>>> * >>>>> *

If this signature has been previously initialized with parameters >>>>> * (by calling the {@code setParameter} method), this method returns >>>>> * the same parameters. If this signature has not been initialized with >>>>> * parameters, this method may return a combination of default and >>>>> * randomly generated parameter values if the underlying >>>>> * signature implementation supports it and can successfully generate >>>>> * them. Otherwise, {@code null} is returned. >>>>> * >>>>> * @return the parameters used with this signature, or {@code null} >>>>> */ >>>>> >>>>> In the first sentence of the 2nd paragraph above, I wanted to first list the case where the signature is initialized with parameters, which is the most clear-cut case of what the behavior will be. Then I described the case where an implementation may return default/generated parameters -- and this is clearly marked "may" since it is optional. All other cases other than those two always return null, so I think this makes it easier to understand. >>>>> >>>>> --Sean >>>>> >>>>>> On 7/18/18 1:29 PM, Valerie Peng wrote: >>>>>> Sean, >>>>>> >>>>>> Where do you think that we should add the part about "null must be returned ..." paragraph? At the end of first or second paragraph? >>>>>> >>>>>> I will go with majority. >>>>>> >>>>>> Valerie >>>>>> >>>>>>> On 7/17/2018 8:38 PM, Weijun Wang wrote: >>>>>>> Is it better to append the new lines to the 2nd paragraph? >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> On Jul 18, 2018, at 9:46 AM, Valerie Peng wrote: >>>>>>>> >>>>>>>> >>>>>>>> Ok, let's use "must" then. I have also added the part about default parameters. >>>>>>>> Hope that all is clear now. >>>>>>>> >>>>>>>> Latest webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.03/ >>>>>>>> Latest CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 7/17/2018 5:50 PM, Weijun Wang wrote: >>>>>>>>>> On Jul 18, 2018, at 8:23 AM, Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> Thanks for the suggestions. Please find comments inline. >>>>>>>>>> >>>>>>>>>>> On 7/16/2018 7:38 PM, Weijun Wang wrote: >>>>>>>>>>> CSR at https://bugs.openjdk.java.net/browse/JDK-8206864. >>>>>>>>>>> >>>>>>>>>>> - At the end of the 1st paragraph, you have now >>>>>>>>>>> >>>>>>>>>>>> However, for signature algorithm such as "RSASSA-PSS", it requires parameters and the one used for signing must be supplied for verification to succeed. It may be better to return null instead of returning provider-specific default parameters. >>>>>>>>>>> I suggest we don't talk about the reason (params must be the same for signing and verification), we can just say something like "If there is no provider-specific default parameters, this method should return null before user sets one". >>>>>>>>>> Alright, I initially didn't put down the reason. But since Brad asked about it, I add it to the CSR in case Joe raise the same question. I will update the CSR per your suggestion. >>>>>>>>>>> - null may be returned >>>>>>>>>>> >>>>>>>>>>> How about "{@code null} must be returned"? >>>>>>>>>> How about "should"? Is there a guideline on when to use "may/should/must"? Anyone knows? >>>>>>>>> Even if there were guidelines on this for Java, I think we should just stick to https://tools.ietf.org/html/rfc2119, except that the capitalization is not necessary. >>>>>>>>> >>>>>>>>> "Must" is precise here. >>>>>>>>> >>>>>>>>>> I thought must is mostly used in mandating input arguments must not be null. But don't recall it being used much for return values. >>>>>>>>> "must return" appears 39 times in java/ and "should return" 19 (simple grep, no line break). >>>>>>>>> >>>>>>>>> --Max >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>>> Everything else looks fine. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>>> On Jul 17, 2018, at 9:46 AM, Valerie Peng wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> Good catch on the SignatureSpi class and SunMSCAPI provider, I will include them. >>>>>>>>>>>> >>>>>>>>>>>> As for the part about "randomly generated", I am leaning toward not having it as I don't see a value of specifying this. >>>>>>>>>>>> >>>>>>>>>>>> Webrev and CSR has been updated. >>>>>>>>>>>> >>>>>>>>>>>> New webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.02/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Valerie >>>>>>>>>>>> >>>>>>>>>>>>> On 7/16/2018 4:29 PM, Weijun Wang wrote: >>>>>>>>>>>>> Valerie >>>>>>>>>>>>> >>>>>>>>>>>>> Would you like to retain the word "randomly generated" somewhere? >>>>>>>>>>>>> >>>>>>>>>>>>> Also, the SignatureSpi class needs to be updated in the same way. >>>>>>>>>>>>> >>>>>>>>>>>>> Can you also update the implementation in the MSCAPI Signature object? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>>> On Jul 17, 2018, at 6:16 AM, Valerie Peng wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> No issues found and it seems ok to return null if no parameters is set. Thus, I have updated the webrev and CSR accordingly. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.01/ >>>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 7/13/2018 11:05 AM, Valerie Peng wrote: >>>>>>>>>>>>>>> Hmm, I like the idea of expanding null to cover both cases. >>>>>>>>>>>>>>> I will explore it more and see. >>>>>>>>>>>>>>> Thanks for the feedback, >>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 7/13/2018 6:56 AM, Sean Mullan wrote: >>>>>>>>>>>>>>>> On 7/12/18 10:23 PM, Weijun Wang wrote: >>>>>>>>>>>>>>>>>> On Jul 13, 2018, at 10:01 AM, Valerie Peng wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The javadoc is for Signature.getParameters(), so null can be returned for signature algorithms which do not use parameters, e.g. SHA256withDSA. As Signature class covers all signature algorithms, I am not sure about mentioning specific algorithm names as it may be lengthy and even misleading unless we list out all applicable algorithms. >>>>>>>>>>>>>>>>> Sure. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The part of "default and randomly generated" is inherited from existing javadoc. I think "default" in the aforementioned sentence means "hardcoded values". For example, something like salt length will likely have a fixed default value. Since we have no control over 3rd party providers, I think we may have to keep this for backward compatibility reason. For RSASSA-PSS sig algorithm, it errors out if the required parameter is not given. Thus, I added the sentence "If there are no provider-specific default values, the underlying signature implementation may also fail". >>>>>>>>>>>>>>>>> OK, now I understand "a combination of default and randomly generated" means some part of the parameter is hardcoded and some is random. Anyway, let's keep it unchanged. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Then, how about simply "If there are no provider-specific values" which covers both hardcoded and random values? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "the underlying signature implementation may also fail" is still not clear to me. If I had not read the CSR I would thought an exception will be thrown when update/sign is called. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As for @throws, I debated about it. The main reason for not adding one is consistency. Many (or should I say most) security classes do not have @throws for ProviderException. If we were to add @throws ProviderException here, we should do it across the board. Besides, it is recommended to NOT document runtime exceptions which callers are not prepared to handle. >>>>>>>>>>>>>>>>> I assume other getParameters() had not added it is because it happened they can return one. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> While people does not catch runtime exceptions but my understanding is that if you mentioned "fail" in the spec maybe it's better to add a @throws for it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For example, @throws SecurityException for File/Files operations. >>>>>>>>>>>>>>>> Thinking more about this, I would be more inclined to recommend that you change the meaning of null as the return value to cover both cases: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> @return the parameters used with this signature, or null if this signature does not use any parameters or does not support default or randomly generated parameter values >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I don't think it is critical to make a distinction between these 2 cases, because if the programmer doesn't initialize it with parameters it will get a SignatureException anyway when it tries to call sign or verify. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It's not perfect, but probably the best you can do working within the constraints of that API and minimizing compatibility risk. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --Sean >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 7/10/2018 7:16 PM, Weijun Wang wrote: >>>>>>>>>>>>>>>>>>> Hi Valerie >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> About "it *may* return", do you mean it could also return null? My understanding is no. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Is it better to clarify when the implementation "may also fail"? From the CSR, it's this method. Can you add a @throws spec to this method then? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also, I am a little confused by "default and randomly generated". Does this actually mean "default (might be randomly generated)"? The "it may" sentence mentions "default and randomly generated" but the "if there" only says "default", which sounds like the the "randomly generated" case could be different. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Jul 11, 2018, at 5:12 AM, Valerie Peng wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Brad, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Would you have time to review the fix for JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized? >>>>>>>>>>>>>>>>>>>> No source code changes, but just updating javadoc to mention the possible failure case. >>>>>>>>>>>>>>>>>>>> Otherwise, JCK team expects a parameter object or null being returned. >>>>>>>>>>>>>>>>>>>> I filed a CSR to track the javadoc clarification. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206171 >>>>>>>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8206171/webrev.00/ >>>>>>>>>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8206864 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> From valerie.peng at oracle.com Wed Jul 25 02:00:36 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 24 Jul 2018 19:00:36 -0700 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Message-ID: Hi Martin, Sorry for the delay, I am able to resume on reviewing this now. Here are some initial comments. What about CKM_TLS12_MAC? I see that it's defined under TLS 1.2 mechanisms, but not much other details for it. - Is this change still necessary? I didn't notice any new import statement with sun.security.ssl package in the rest of changes. - Why removing the SENSITIVE_FALSE attribute on line 829 and 854? - As my comments for the SunPKCS11.java (see below), I think we should not assume the support for CKM_TLS12_KEY_AND_MAC_DERIVE. The existing impl and how it's registered in SunPKCS11 class is already somewhat problematic when CKM_TLS_KEY_AND_MAC_DERIVE is not supported. We should avoid assuming CKM_TLS12_KEY_AND_MAC_DERIVE is supported which may create even more problems. Overriding this.mechanism based on the TLS version specified in the parameters from the engineInit(...) call will lead to failure when the mechanism is not supported by underlying PKCS11 library - Please see above comments for P11TlsKeyMaterialGenerator.java - Retrieve label outside of the new code block for TLS 1.2, i.e. line 133- 167, as it's used by all mechanisms. - Line 131, Is it really necessary to use SunTls12RsaPremasterSecret? SunJCE provider uses SunTlsRsaPremasterSecret for all cases. If different algorithm is not needed, then no need to save tlsVersion as a field - Hmm, for TLS 12 specific mechanisms, some PKCS11 libraries may not support them. Instead of registering SunTls12MasterSecret/SunTls12KeyMaterial as aliases, they should be registered separately so that if the native TLS 12 mechanisms were not supported, the new entry will be skipped. The corresponding implementation classes such as P11TlsMasterSecretGenerator and P11TlsKeyMaterialGenerator will have to check the specified parameter spec in their engineInit(..) calls to make sure things line up, e.g. error out if the TLS version in the spec does not match the native mechanism. - Lines 528 - 532, the mapping is stored without checking for support. May become an issue when the underlying PKCS11 library does not support all of these hash mechanisms. Probably not a big deal as these are fairly common hash algorithms, but I think it'd be good to add a comment on line 527 with something like "// assuming all hash mechanisms below are supported". - Miss the mapping for CKM_TLS12_KEY_AND_MAC_DERIVE? Move these new entries to be after the existing SSL3/TLS entries (from line 711-721) I still have a few files left and will send you comments on them later. Thanks, Valerie On 7/13/2018 2:08 PM, Valerie Peng wrote: > > Thanks for updating the webrev, I will take a look. > > Valerie > > > On 7/10/2018 10:18 AM, Martin Balao wrote: >> Hi, >> >> Webrev 04 for JDK-8029661 is ready: >> >> ?* >> http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.04.zip >> >> ?* >> http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.04/ >> >> >> New: >> >> ?* Rebased to latest JDK revision (after TLS 1.3 merge) >> ? * Rev 1acfd2f56d72 >> ?* ProtocolVersion dependencies removed (raw TLS protocol version >> numbers are now used) >> ?* Code style improvements (tabs, trailing whitespaces, max lines >> length, etc.) >> >> Thanks, >> Martin.- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Wed Jul 25 14:29:41 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 25 Jul 2018 10:29:41 -0400 Subject: Please review EdDSA API Message-ID: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> The draft CSR[1] for the EdDSA API[2] is ready for review. Please take a look and send me any feedback you may have. Here are a few high-level notes to explain the API: 1) Where possible, this API is similar to the API for X25519/X448. To get the complete background/motivation for the API design, you can review the discussion[3] on this topic. 2) Similar to X25519/X448, private keys are byte arrays, and public keys coordinates. Though we can't get by with a single BigInteger coordinate for EdDSA, so I am using the new EdPoint class to hold the coordinates. 3) EdDSA has multiple signature modes defined in the RFC[4], including some that "prehash" the input before signing. The draft API uses the EdDSAParameterSpec class to specify parameters of these modes. The standard does not allow an arbitrary choice of prehash function, so the API for EdDSA does not support algorithm names like "SHA256withEdDSA". [1] https://wiki.openjdk.java.net/display/csr/Main [2] https://bugs.openjdk.java.net/browse/JDK-8190219 [3] http://mail.openjdk.java.net/pipermail/security-dev/2017-September/016325.html [4] https://tools.ietf.org/html/rfc8032 From adam.petcher at oracle.com Wed Jul 25 15:07:53 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 25 Jul 2018 11:07:53 -0400 Subject: Please review EdDSA API In-Reply-To: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> References: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> Message-ID: <3801e4b5-8df4-6201-6d3f-6689fdb7f00d@oracle.com> +core-libs-dev for additional API expertise. On 7/25/2018 10:29 AM, Adam Petcher wrote: > The draft CSR[1] for the EdDSA API[2] is ready for review. Please take > a look and send me any feedback you may have. Here are a few > high-level notes to explain the API: > > 1) Where possible, this API is similar to the API for X25519/X448. To > get the complete background/motivation for the API design, you can > review the discussion[3] on this topic. > 2) Similar to X25519/X448, private keys are byte arrays, and public > keys coordinates. Though we can't get by with a single BigInteger > coordinate for EdDSA, so I am using the new EdPoint class to hold the > coordinates. > 3) EdDSA has multiple signature modes defined in the RFC[4], including > some that "prehash" the input before signing. The draft API uses the > EdDSAParameterSpec class to specify parameters of these modes. The > standard does not allow an arbitrary choice of prehash function, so > the API for EdDSA does not support algorithm names like > "SHA256withEdDSA". > > [1] https://wiki.openjdk.java.net/display/csr/Main > [2] https://bugs.openjdk.java.net/browse/JDK-8190219 > [3] > http://mail.openjdk.java.net/pipermail/security-dev/2017-September/016325.html > [4] https://tools.ietf.org/html/rfc8032 > From jamil.j.nimeh at oracle.com Wed Jul 25 15:14:04 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 25 Jul 2018 08:14:04 -0700 Subject: RFR: Backport for JDK-8207237 to JDK 11 Message-ID: <4371a673-a2d6-5a34-1f95-3004b3418b3a@oracle.com> Hi folks, This is a review for a backport to the JDK 11 repo of a change I did earlier to jdk/jdk that fixed the SSLSocket.setEnabledCipherSuites method.? It no longer accepts empty strings in the cipher suite list.? Instread, it returns to the behavior of throwing IllegalArgumentException as it did before the new TLS handshaker code was committed. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8207237-jdk11/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8207237 Thanks, --Jamil From xuelei.fan at oracle.com Wed Jul 25 15:17:22 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 25 Jul 2018 08:17:22 -0700 Subject: RFR: Backport for JDK-8207237 to JDK 11 In-Reply-To: <4371a673-a2d6-5a34-1f95-3004b3418b3a@oracle.com> References: <4371a673-a2d6-5a34-1f95-3004b3418b3a@oracle.com> Message-ID: <5d8a87ca-38d9-a30d-abaf-c0b25a598068@oracle.com> Looks fine to me. Xuelei On 7/25/2018 8:14 AM, Jamil Nimeh wrote: > Hi folks, > > This is a review for a backport to the JDK 11 repo of a change I did > earlier to jdk/jdk that fixed the SSLSocket.setEnabledCipherSuites > method.? It no longer accepts empty strings in the cipher suite list. > Instread, it returns to the behavior of throwing > IllegalArgumentException as it did before the new TLS handshaker code > was committed. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8207237-jdk11/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8207237 > > Thanks, > > --Jamil > From mstjohns at comcast.net Wed Jul 25 15:24:07 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 25 Jul 2018 11:24:07 -0400 Subject: Please review EdDSA API In-Reply-To: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> References: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> Message-ID: <9cedfc60-164d-a6a5-a65a-45bad779cd36@comcast.net> On 7/25/2018 10:29 AM, Adam Petcher wrote: > 2) Similar to X25519/X448, private keys are byte arrays, and public > keys coordinates. Though we can't get by with a single BigInteger > coordinate for EdDSA, so I am using the new EdPoint class to hold the > coordinates. *sigh* Private keys are big integers.? There's an associated parameter used in signing that the implementation described in the RFC (*not a standard please note*) generates from a common random byte array - that byte array is NOT a (or the) private key. E.g.?????? Private key ::= OctetToInteger(Adjust(Left (HASH(random), length))) and SigningValue ::= Right(HASH(random),length). Instead, you can get the exact same result (deterministic signatures) - and store a bog standard EC private key - by PrivateKey ::= OctetToInteger(Adjust(random)); SigningValue ::= HASH (IntegerToOctet(PrivateKey)); // signing value may be regenerated at any time and need not be stored in the ECPrivateKey class. Adjust twiddles the bits in the byte array to make the byte array a valid little-endian private key before encoding for this set of curves.? OctetToInteger turns that byte array into a BigInteger. At this point in time, you've got the correct values to do your point math using common libraries if you don't happen to have implemented exactly what's in the RFC. I know the above is a losing argument, but seriously, do we really need two new groups of EC classes simply because someone wrote an RFC that didn't consider existing representational structures? Or will it be three or more? Later, Mike From adam.petcher at oracle.com Wed Jul 25 18:05:25 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 25 Jul 2018 14:05:25 -0400 Subject: Please review EdDSA API In-Reply-To: <9cedfc60-164d-a6a5-a65a-45bad779cd36@comcast.net> References: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> <9cedfc60-164d-a6a5-a65a-45bad779cd36@comcast.net> Message-ID: On 7/25/2018 11:24 AM, Michael StJohns wrote: > > *sigh* Private keys are big integers.? There's an associated parameter > used in signing that the implementation described in the RFC (*not a > standard please note*) generates from a common random byte array - > that byte array is NOT a (or the) private key. > > E.g.?????? Private key ::= OctetToInteger(Adjust(Left (HASH(random), > length))) and SigningValue ::= Right(HASH(random),length). > > Instead, you can get the exact same result (deterministic signatures) > - and store a bog standard EC private key - by > > PrivateKey ::= OctetToInteger(Adjust(random)); Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing bits here destroys information. If we don't prune here, then we can reverse this operation later to get the byte array back to give to the hash. > > SigningValue ::= HASH (IntegerToOctet(PrivateKey)); // signing value > may be regenerated at any time and need not be stored in the > ECPrivateKey class. With the modification above, I agree that this would give the value that can be split in half to produce the scalar value (after pruning and interpreting as an integer) and the prefix that is used in signing. I think there may be some issues with this approach, but we need to start by agreeing on what you are proposing. Can you confirm that my understanding of your proposal is correct, or else clarify it for me? From xuelei.fan at oracle.com Wed Jul 25 18:30:32 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 25 Jul 2018 11:30:32 -0700 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 Message-ID: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> Hi, Please review the update for JDK-8208166: http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8208166 Thanks, Xuelei From valerie.peng at oracle.com Wed Jul 25 22:39:29 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 25 Jul 2018 15:39:29 -0700 Subject: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found In-Reply-To: <95234233-a35f-8a48-7f22-73f058524601@oracle.com> References: <905d69d6-1112-0b53-9124-f53c783fa803@oracle.com> <177a4bf1-da82-4b70-abad-6ac794fea9e6@oracle.com> <95234233-a35f-8a48-7f22-73f058524601@oracle.com> Message-ID: Updated webrev looks fine. Thanks, Valerie On 7/23/2018 11:10 PM, sha.jiang at oracle.com wrote: > Hi Valerie, > Thanks for your review! > Please take a look at this new webrev: > http://cr.openjdk.java.net/~jjiang/8206258/webrev.02 > > On 2018/7/24 06:18, Valerie Peng wrote: >> Hi John, >> >> Changes look fine. >> >> I just have one nit, perhaps add more information reporting when >> skipping tests, e.g. >> >> PKCS11Test: line 163 > Different tests may have different reasons for skipping testing. > So, it would be better to output the info in PKCS11Test's child classes. > In fact, the tests overriding the method PKCS11Test::skipTest already > report the reasons respectively. > >> TestNssDbSqlite.java: line 68. > Add the below line > 120???????????? System.out.println("Cannot init security module > database, skipping"); > > Best regards, > John Jiang >> >> Thanks, >> Valerie >> >> On 7/9/2018 12:38 AM, sha.jiang at oracle.com wrote: >>> Hi Thomas, >>> Thanks for your testing. >>> >>> I'm not sure that's a reasonable case. >>> From my view, PKCS11Test.java simply checks if the NSS library >>> directory exists. >>> But it looks unnecessary to check every library file. >>> In fact, if removing libnss3 or libsoftokn3's dependencies, like >>> libnssutil3, the test also fails. >>> >>> However, I still re-checked my previous solution, and made a new >>> webrev [1]. >>> The constant badNSSVersion in PKCS11Test.java may not be fine. >>> The static field nss_library in PKCS11Test.java can be softokn3 or >>> nss3 for different tests. >>> badNSSVersion should be checked after the target nss library is >>> determined. >>> And this checking should happen before the real testing, especially >>> before security manager is enabled. >>> So, a new extension method, exactly PKCS11Test::skipTest, was >>> introduced, and the affected tests were modified accordingly. >>> >>> [1] http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ >>> >>> Best regards, >>> John Jiang >>> >>> On 2018/7/4 14:15, Thomas St?fe wrote: >>>> Hi, >>>> >>>> Unfortunately this is not enough. >>>> >>>> Running tests with your patch and NSS libs disabled (I renamed >>>> libsoftokn3.so) yields the following errors: >>>> >>>> sun/security/pkcs11/Secmod/AddPrivateKey.java >>>> ????????????????????????????????????????????????? Failed. Execution >>>> failed: `main' threw exception: java.security.ProviderException: Could >>>> not initialize NSS >>>> sun/security/pkcs11/Secmod/AddTrustedCert.java >>>> ????????????????????????????????????????????????? Failed. Execution >>>> failed: `main' threw exception: java.security.ProviderException: Could >>>> not initialize NSS >>>> sun/security/pkcs11/Secmod/Crypto.java >>>> ????????????????????????????????????????????????? Failed. Execution >>>> failed: `main' threw exception: java.security.ProviderException: Could >>>> not initialize NSS >>>> sun/security/pkcs11/Secmod/GetPrivateKey.java >>>> ????????????????????????????????????????????????? Failed. Execution >>>> failed: `main' threw exception: java.security.ProviderException: Could >>>> not initialize NSS >>>> sun/security/pkcs11/Secmod/JksSetPrivateKey.java >>>> ????????????????????????????????????????????????? Failed. Execution >>>> failed: `main' threw exception: java.security.ProviderException: Could >>>> not initialize NSS >>>> sun/security/pkcs11/Secmod/LoadKeystore.java >>>> ????????????????????????????????????????????????? Failed. Execution >>>> failed: `main' threw exception: java.security.ProviderException: Could >>>> not initialize NSS >>>> sun/security/pkcs11/Secmod/TestNssDbSqlite.java >>>> ????????????????????????????????????????????????? Failed. Execution >>>> failed: `main' threw exception: java.security.ProviderException: Could >>>> not initialize NSS >>>> sun/security/pkcs11/Secmod/TrustAnchors.java >>>> ????????????????????????????????????????????????? Failed. Execution >>>> failed: `main' threw exception: java.security.ProviderException: Could >>>> not initialize NSS >>>> >>>> >>>> Excerpt from TestNssDbSqlite.jtr: >>>> >>>> ----------messages:(3/98)---------- >>>> command: build TestNssDbSqlite >>>> reason: Named class compiled on demand >>>> elapsed time (seconds): 0.0 >>>> result: Passed. All files up to date >>>> >>>> #section:main >>>> ----------messages:(5/721)---------- >>>> command: main TestNssDbSqlite >>>> reason: User specified action: run main/othervm/timeout=120 >>>> TestNssDbSqlite >>>> Mode: othervm [/othervm specified] >>>> Additional options from @modules: --add-modules >>>> java.base,jdk.crypto.cryptoki --add-exports >>>> java.base/sun.security.rsa=ALL-UNNAMED --add-exports >>>> java.base/sun.security.provider=ALL-UNNAMED --add-exports >>>> java.base/sun.security.jca=ALL-UNNAMED --add-exports >>>> java.base/sun.security.tools.keytool=ALL-UNNAMED --add-exports >>>> java.base/sun.security.x509=ALL-UNNAMED --add-exports >>>> java.base/com.sun.crypto.provider=ALL-UNNAMED --add-exports >>>> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED --add-opens >>>> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED >>>> elapsed time (seconds): 0.445 >>>> ----------configuration:(11/604)---------- >>>> Boot Layer >>>> ?? add modules: java.base jdk.crypto.cryptoki >>>> ?? add exports: java.base/com.sun.crypto.provider ALL-UNNAMED >>>> ??????????????? java.base/sun.security.jca ALL-UNNAMED >>>> ??????????????? java.base/sun.security.provider ALL-UNNAMED >>>> ??????????????? java.base/sun.security.rsa ALL-UNNAMED >>>> ??????????????? java.base/sun.security.tools.keytool ALL-UNNAMED >>>> ??????????????? java.base/sun.security.x509 ALL-UNNAMED >>>> ??????????????? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >>>> ?? add opens:?? jdk.crypto.cryptoki/sun.security.pkcs11 ALL-UNNAMED >>>> >>>> ----------System.out:(1/64)---------- >>>> Warning: can't find NSS librarys on this machine, skipping test >>>> ----------System.err:(25/1633)---------- >>>> java.security.ProviderException: Could not initialize NSS >>>> at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:218) >>>> at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) >>>> at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) >>>> at java.base/java.security.AccessController.doPrivileged(Native >>>> Method) >>>> at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) >>>> at PKCS11Test.getSunPKCS11(PKCS11Test.java:152) >>>> at TestNssDbSqlite.initializeProvider(TestNssDbSqlite.java:121) >>>> at TestNssDbSqlite.initialize(TestNssDbSqlite.java:112) >>>> at TestNssDbSqlite.main(TestNssDbSqlite.java:67) >>>> 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:115) >>>> at java.base/java.lang.Thread.run(Thread.java:834) >>>> Caused by: java.io.IOException: NSS initialization failed >>>> at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:234) >>>> at >>>> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:213) >>>> ... 14 more >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> On Wed, Jul 4, 2018 at 7:36 AM, wrote: >>>>> Hi, >>>>> If NSS libs are unavailable, PKCS11 tests fail when checking NSS >>>>> version. >>>>> This patch tries to fix this issue. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206258 >>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.00/ >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >>> >> >> > From mark.reinhold at oracle.com Wed Jul 25 23:00:27 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 25 Jul 2018 16:00:27 -0700 (PDT) Subject: New candidate JEP: 339: Edwards-Curve Digital Signature Algorithm (EdDSA) Message-ID: <20180725230027.2B4C51E177C@eggemoggin.niobe.net> http://openjdk.java.net/jeps/339 - Mark From norman.maurer at googlemail.com Thu Jul 26 06:22:21 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 26 Jul 2018 08:22:21 +0200 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> Message-ID: Just FYI? I tested this patch via the netty ssl tests and we no longer see the class-cast-exception problems I reported before dso I think this solves the issue. That said we still encounter a few test-failures for tests that test behaviour of closing outbound of the SSLEngine but I think these are more related to http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html and http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html . Bye Norman > On 25. Jul 2018, at 20:30, Xuelei Fan wrote: > > Hi, > > Please review the update for JDK-8208166: > http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8208166 > > Thanks, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Jul 26 14:36:57 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 26 Jul 2018 15:36:57 +0100 Subject: RFR: 8207775: Better management of CipherCore buffers Message-ID: https://bugs.openjdk.java.net/browse/JDK-8207775 Simple enough fix to null out some internal buffers once they're no longer required. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/ regards, Sean. From mbalao at redhat.com Thu Jul 26 16:12:02 2018 From: mbalao at redhat.com (Martin Balao) Date: Thu, 26 Jul 2018 13:12:02 -0300 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Message-ID: Hi Valerie, Thanks for your feedback! CKM_TLS12_MAC looks like it's not in use. Authentication codes are calculated through CKM_TLS12_KEY_AND_MAC_DERIVE mechanism. Do you know of a library supporting CKM_TLS12_MAC but not CKM_TLS12_KEY_AND_MAC_DERIVE? I've been testing this with NSS software token which does not support CKM_TLS12_MAC. module-info.java changes were from when we used SSL/TLS constants, but then I replaced these constants with hardcoded numbers -after discussing with Xuelei-. I forgot to revert changes on this file. Thanks. Config.java changes were from a wrong version I uploaded. This has been already fixed. SunPKCS11.java: I agree with you that registration must be done separately. SunTls12MasterSecret and SunTls12KeyMaterial are now registered separately. I've added CKM_TLS12_MASTER_KEY_DERIVE_DH mechanism to SunTls12MasterSecret algorithm. It's still assumed that if CKM_TLS12_MASTER_KEY_DERIVE is supported, then CKM_TLS12_MASTER_KEY_DERIVE_DH it's and vice-versa -same as with previous key derivation mechanisms-. Not a big deal though I think: it's unlikely that a library implements only one of these. Using protocol version to decide which mechanism to use should be valid in this case because if an instance of P11TlsMasterSecretGenerator is used and algorithm is SunTls12MasterSecret, then protocol must be TLS 1.2 and we can assume that there is support of these mechanisms in the underlying library. L527: I've realized that a better place for this map is Functions.java. I've moved it there. P11TlsPrfGenerator.java: This code is for TLS 1.2 only. That's because CKM_TLS_MAC mechanism is registered for SunTls12Prf algorithm. Previous TLS versions use CKM_TLS_PRF and CKM_NSS_TLS_PRF_GENERAL. P11TlsRsaPremasterSecretGenerator.java: Yes, we can remove it and call all keys "TlsRsaPremasterSecret", disregarding the mechanism used to generate it (CKM_SSL3_PRE_MASTER_KEY_GEN or CKM_TLS_PRE_MASTER_KEY_GEN). At the end of the day, this is just an array of 48 bytes. I've removed the field too. Functions.java: New entries (CKM_TLS12_MASTER_KEY_DERIVE, CKM_TLS12_MASTER_KEY_DERIVE_DH and CKM_TLS_MAC) moved after line 721. CKM_TLS12_KEY_AND_MAC_DERIVE has been added for completeness. CK_ATTRIBUTE.java: SENSITIVE_TRUE removed. Removed a dependency in TestTLS12.java to HexDumper (internal). Webrev 06 with all these changes here: * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06/ * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06.zip Regression testing on jdk/sun/security/pkcs11 passes with samae pass rate. Kind regards, Martin.- On Tue, Jul 24, 2018 at 11:00 PM, Valerie Peng wrote: > Hi Martin, > > Sorry for the delay, I am able to resume on reviewing this now. > > Here are some initial comments. > > What about CKM_TLS12_MAC? I see that it's defined under TLS 1.2 > mechanisms, but not much other details for it. > > - Is this change still necessary? I didn't notice any new import statement > with sun.security.ssl package in the rest of changes. > > > - Why removing the SENSITIVE_FALSE attribute on line 829 and 854? > > > - As my comments for the SunPKCS11.java (see below), I think we should not > assume the support for CKM_TLS12_KEY_AND_MAC_DERIVE. The existing impl and > how it's registered in SunPKCS11 class is already somewhat problematic when > CKM_TLS_KEY_AND_MAC_DERIVE is not supported. We should avoid assuming > CKM_TLS12_KEY_AND_MAC_DERIVE is supported which may create even more > problems. Overriding this.mechanism based on the TLS version specified in > the parameters from the engineInit(...) call will lead to failure when the > mechanism is not supported by underlying PKCS11 library > > > - Please see above comments for P11TlsKeyMaterialGenerator.java > > > - Retrieve label outside of the new code block for TLS 1.2, i.e. line 133- > 167, as it's used by all mechanisms. > > > - Line 131, Is it really necessary to use SunTls12RsaPremasterSecret? > SunJCE provider uses SunTlsRsaPremasterSecret for all cases. If different > algorithm is not needed, then no need to save tlsVersion as a field > > > - Hmm, for TLS 12 specific mechanisms, some PKCS11 libraries may not > support them. Instead of registering SunTls12MasterSecret/SunTls12KeyMaterial > as aliases, they should be registered separately so that if the native TLS > 12 mechanisms were not supported, the new entry will be skipped. The > corresponding implementation classes such as P11TlsMasterSecretGenerator > and P11TlsKeyMaterialGenerator will have to check the specified parameter > spec in their engineInit(..) calls to make sure things line up, e.g. error > out if the TLS version in the spec does not match the native mechanism. > - Lines 528 - 532, the mapping is stored without checking for support. May > become an issue when the underlying PKCS11 library does not support all of > these hash mechanisms. Probably not a big deal as these are fairly common > hash algorithms, but I think it'd be good to add a comment on line 527 with > something like "// assuming all hash mechanisms below are supported". > > > - Miss the mapping for CKM_TLS12_KEY_AND_MAC_DERIVE? Move these new > entries to be after the existing SSL3/TLS entries (from line 711-721) > > I still have a few files left and will send you comments on them later. > Thanks, > Valerie > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Thu Jul 26 16:42:09 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 26 Jul 2018 09:42:09 -0700 Subject: RFR: 8207775: Better management of CipherCore buffers In-Reply-To: References: Message-ID: On 07/26/2018 07:36 AM, Se?n Coffey wrote: > https://bugs.openjdk.java.net/browse/JDK-8207775 > > Simple enough fix to null out some internal buffers once they're no > longer required. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/ > > regards, > Sean. > that looks fine.. Tony From mstjohns at comcast.net Thu Jul 26 19:58:43 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 26 Jul 2018 15:58:43 -0400 Subject: Please review EdDSA API In-Reply-To: References: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> <9cedfc60-164d-a6a5-a65a-45bad779cd36@comcast.net> Message-ID: <1e431219-80b8-e5d3-9e97-b893f682b365@comcast.net> On 7/25/2018 2:05 PM, Adam Petcher wrote: > On 7/25/2018 11:24 AM, Michael StJohns wrote: > >> >> *sigh* Private keys are big integers.? There's an associated >> parameter used in signing that the implementation described in the >> RFC (*not a standard please note*) generates from a common random >> byte array - that byte array is NOT a (or the) private key. >> >> E.g.?????? Private key ::= OctetToInteger(Adjust(Left (HASH(random), >> length))) and SigningValue ::= Right(HASH(random),length). >> >> Instead, you can get the exact same result (deterministic signatures) >> - and store a bog standard EC private key - by >> >> PrivateKey ::= OctetToInteger(Adjust(random)); > > Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing > bits here destroys information. If we don't prune here, then we can > reverse this operation later to get the byte array back to give to the > hash. No - I meant what I wrote: 1) generate a private key from a random and store it as a big integer.? E.g. generate a byte array of the appropriate length (32), twiddle the bits as described in step 2 of section 5.1.5 of RFC8032 and - interpreting that buffer as a little-endian encoding, save 's' (the secret scalar - aka - the actual private key) as a BigInteger. That's the limit of what goes into the PrivateKey spec/interface. 2) When you do a signing, do SigningValue = HASH(IntegerToLittleEndianOctets(s)). 3) When done with signing, throw away the hash value - it doesn't need to be stored. The *only* important characteristics of the signing value are a) it's confidential, and b) it's the same for each signature.? It could even be a random value generated and stored at the same time as the private key - but why? > >> >> SigningValue ::= HASH (IntegerToOctet(PrivateKey)); // signing value >> may be regenerated at any time and need not be stored in the >> ECPrivateKey class. > > With the modification above, I agree that this would give the value > that can be split in half to produce the scalar value (after pruning > and interpreting as an integer) and the prefix that is used in signing. > > I think there may be some issues with this approach, but we need to > start by agreeing on what you are proposing. Can you confirm that my > understanding of your proposal is correct, or else clarify it for me? What I'm trying to get to is make the java interfaces for EC private keys consistent regardless of which of the curve flavor you want to use.?? In each and every case, looking behind the specified external representation, the scalar 's' can be represented as a BigInteger. Internal representation IN A SPECIFIC IMPLEMENTATION might use little endian internally, but that's irrelevant here for the purposes of java interfaces.??? (At least in my opinion). Later, Mike From adam.petcher at oracle.com Thu Jul 26 20:24:49 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 26 Jul 2018 16:24:49 -0400 Subject: Please review EdDSA API In-Reply-To: <1e431219-80b8-e5d3-9e97-b893f682b365@comcast.net> References: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> <9cedfc60-164d-a6a5-a65a-45bad779cd36@comcast.net> <1e431219-80b8-e5d3-9e97-b893f682b365@comcast.net> Message-ID: <48c03962-9b49-4183-d98a-cf54e87f2058@oracle.com> On 7/26/2018 3:58 PM, Michael StJohns wrote: > On 7/25/2018 2:05 PM, Adam Petcher wrote: >> >> Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing >> bits here destroys information. If we don't prune here, then we can >> reverse this operation later to get the byte array back to give to >> the hash. > > No - I meant what I wrote: > > 1) generate a private key from a random and store it as a big > integer.? E.g. generate a byte array of the appropriate length (32), > twiddle the bits as described in step 2 of section 5.1.5 of RFC8032 > and - interpreting that buffer as a little-endian encoding, save 's' > (the secret scalar - aka - the actual private key) as a BigInteger. > > That's the limit of what goes into the PrivateKey spec/interface. > 2) When you do a signing, do SigningValue = > HASH(IntegerToLittleEndianOctets(s)). > 3) When done with signing, throw away the hash value - it doesn't need > to be stored. > Does this produce the same result as the signing function described in sections 3.2 and 3.3 of the RFC? If I do as you suggest, will the test vectors in Section 7 pass? It's not obvious to me that the signing procedure that you are proposing is the same function. From mstjohns at comcast.net Thu Jul 26 21:05:27 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 26 Jul 2018 17:05:27 -0400 Subject: Please review EdDSA API In-Reply-To: <48c03962-9b49-4183-d98a-cf54e87f2058@oracle.com> References: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> <9cedfc60-164d-a6a5-a65a-45bad779cd36@comcast.net> <1e431219-80b8-e5d3-9e97-b893f682b365@comcast.net> <48c03962-9b49-4183-d98a-cf54e87f2058@oracle.com> Message-ID: On 7/26/2018 4:24 PM, Adam Petcher wrote: > On 7/26/2018 3:58 PM, Michael StJohns wrote: > >> On 7/25/2018 2:05 PM, Adam Petcher wrote: >>> >>> Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing >>> bits here destroys information. If we don't prune here, then we can >>> reverse this operation later to get the byte array back to give to >>> the hash. >> >> No - I meant what I wrote: >> >> 1) generate a private key from a random and store it as a big >> integer.? E.g. generate a byte array of the appropriate length (32), >> twiddle the bits as described in step 2 of section 5.1.5 of RFC8032 >> and - interpreting that buffer as a little-endian encoding, save 's' >> (the secret scalar - aka - the actual private key) as a BigInteger. >> >> That's the limit of what goes into the PrivateKey spec/interface. >> 2) When you do a signing, do SigningValue = >> HASH(IntegerToLittleEndianOctets(s)). >> 3) When done with signing, throw away the hash value - it doesn't >> need to be stored. >> > Does this produce the same result as the signing function described in > sections 3.2 and 3.3 of the RFC? If I do as you suggest, will the test > vectors in Section 7 pass? It's not obvious to me that the signing > procedure that you are proposing is the same function. Note that the signing value (e.g. prefix) is used as part of the formation of 'r' in signing, but is not recoverable from the signature.?? s is calculated from whatever value of r you get and the two taken together (r,s) form the actual signature.?? Note that 'prefix' could be a random value if you wanted non-deterministic signatures, but the inclusion of a fixed prefix value means that the same signature will be generated by the same private key over the same data. The test vectors will not pass, because they are calling the byte array from which the private key and the signing value are derived as the private key. However, each and every signature generated by the above approach (e.g. using a *real* private key and a signing value downstream derived from that private key) *will* verify, and each and every signature by that private key over the same data using the above approach will produce identical signatures. Mike From adam.petcher at oracle.com Thu Jul 26 22:10:05 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 26 Jul 2018 18:10:05 -0400 Subject: Please review EdDSA API In-Reply-To: References: <449fc199-3bb8-8ada-0a23-520d30e7a4e5@oracle.com> <9cedfc60-164d-a6a5-a65a-45bad779cd36@comcast.net> <1e431219-80b8-e5d3-9e97-b893f682b365@comcast.net> <48c03962-9b49-4183-d98a-cf54e87f2058@oracle.com> Message-ID: On 7/26/2018 5:05 PM, Michael StJohns wrote: > The test vectors will not pass, because they are calling the byte > array from which the private key and the signing value are derived as > the private key. > > However, each and every signature generated by the above approach > (e.g. using a *real* private key and a signing value downstream > derived from that private key) *will* verify, and each and every > signature by that private key over the same data using the above > approach will produce identical signatures. > I've stated in the JEP[1] that the goal of this effort is an implementation of EdDSA as described in the RFC. What you are proposing is a slightly different key generation and signing procedure. The fact that the signatures will still verify is not sufficient to convince me that the procedures that you are proposing offer the same security as the ones in the RFC. I understand that you don't like the fact that I am representing the private key value as a byte array instead of an integer. If you can come up with an alternative representation that still allows the same functions that are specified in the RFC, then I will consider it. [1] https://bugs.openjdk.java.net/browse/JDK-8199231 From valerie.peng at oracle.com Thu Jul 26 22:44:46 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 26 Jul 2018 15:44:46 -0700 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Message-ID: <75bdd4b5-1143-958e-dd19-a39a5e120d17@oracle.com> Update: I submitted your webrev.05 through Mach5, there are one test failure observed on 4 configurations, all are due to the regression test TestTLS12.java. It looks like the test fails when the underlying PKCS11 library does not support the corresponding TLS 12 mechanisms (stacktrace included as below) jib > STDERR: jib > java.security.ProviderException: Could not generate key jib > at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsMasterSecretGenerator.engineGenerateKey(P11TlsMasterSecretGenerator.java:181) jib > at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:563) jib > at TestTLS12.testTlsAuthenticationCodeGeneration(TestTLS12.java:181) jib > at TestTLS12.main(TestTLS12.java:104) jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) jib > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) jib > at java.base/java.lang.reflect.Method.invoke(Method.java:566) jib > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) jib > at java.base/java.lang.Thread.run(Thread.java:834) jib > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_MECHANISM_INVALID jib > at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_DeriveKey(Native Method) jib > at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsMasterSecretGenerator.engineGenerateKey(P11TlsMasterSecretGenerator.java:167) jib > ... 9 more jib > jib > JavaTest Message: Test threw exception: java.security.ProviderException: Could not generate key jib > JavaTest Message: shutting down test jib > jib > STATUS:Failed.`main' threw exception: java.security.ProviderException: Could not generate key Thanks, Valerie On 7/23/2018 9:50 PM, Martin Balao wrote: > Hi Valerie, > > Webrev 05: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.05/ > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.05.zip > > > New in Webrev 05: > > ?* Explicitly casted prfHashMechanism to CK_MECHANISM_TYPE type to > avoid building warning on some compilers (it's a long -> unsigned long > cast). > > Regression tests result for jdk/sun/security/pkcs11 category: > > Passed: sun/security/pkcs11/Cipher/JNICheck.java > Passed: sun/security/pkcs11/Cipher/ReinitCipher.java > Passed: sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java > Passed: sun/security/pkcs11/Cipher/TestRawRSACipher.java > Passed: sun/security/pkcs11/Cipher/TestRSACipher.java > Passed: sun/security/pkcs11/Cipher/TestRSACipherWrap.java > Passed: sun/security/pkcs11/Cipher/TestSymmCiphers.java > Passed: sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java > Passed: sun/security/pkcs11/Config/ReadConfInUTF16Env.sh > Passed: sun/security/pkcs11/ec/ReadCertificates.java > Passed: sun/security/pkcs11/ec/ReadPKCS12.java > Passed: sun/security/pkcs11/ec/TestCurves.java > Passed: sun/security/pkcs11/ec/TestECDH.java > Passed: sun/security/pkcs11/ec/TestECDH2.java > Passed: sun/security/pkcs11/ec/TestECDSA.java > Passed: sun/security/pkcs11/ec/TestECDSA2.java > Passed: sun/security/pkcs11/ec/TestECGenSpec.java > FAILED: sun/security/pkcs11/ec/TestKeyFactory.java > Passed: sun/security/pkcs11/fips/ClientJSSEServerJSSE.java > Passed: sun/security/pkcs11/fips/TrustManagerTest.java > Passed: sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java > Passed: sun/security/pkcs11/KeyAgreement/TestDH.java > Passed: sun/security/pkcs11/KeyAgreement/TestInterop.java > Passed: sun/security/pkcs11/KeyAgreement/TestShort.java > Passed: sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java > Passed: sun/security/pkcs11/KeyGenerator/DESParity.java > Passed: sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java > Passed: sun/security/pkcs11/KeyPairGenerator/TestDH2048.java > Passed: sun/security/pkcs11/KeyStore/Basic.sh > Passed: sun/security/pkcs11/KeyStore/ClientAuth.sh > Passed: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh > Passed: sun/security/pkcs11/KeyStore/Solaris.sh > Passed: sun/security/pkcs11/Mac/MacKAT.java > Passed: sun/security/pkcs11/Mac/MacSameTest.java > Passed: sun/security/pkcs11/Mac/ReinitMac.java > Passed: sun/security/pkcs11/MessageDigest/ByteBuffers.java > Passed: sun/security/pkcs11/MessageDigest/DigestKAT.java > Passed: sun/security/pkcs11/MessageDigest/ReinitDigest.java > Passed: sun/security/pkcs11/MessageDigest/TestCloning.java > Passed: sun/security/pkcs11/Provider/Absolute.java > Passed: sun/security/pkcs11/Provider/ConfigQuotedString.sh > Passed: sun/security/pkcs11/Provider/ConfigShortPath.java > Passed: sun/security/pkcs11/Provider/Login.sh > Passed: sun/security/pkcs11/Provider/LoginISE.java > Passed: sun/security/pkcs11/rsa/KeyWrap.java > Passed: sun/security/pkcs11/rsa/TestCACerts.java > Passed: sun/security/pkcs11/rsa/TestKeyFactory.java > Passed: sun/security/pkcs11/rsa/TestKeyPairGenerator.java > Passed: sun/security/pkcs11/rsa/TestSignatures.java > Passed: sun/security/pkcs11/Secmod/AddPrivateKey.java > FAILED: sun/security/pkcs11/Secmod/AddTrustedCert.java > Passed: sun/security/pkcs11/Secmod/Crypto.java > Passed: sun/security/pkcs11/Secmod/GetPrivateKey.java > Passed: sun/security/pkcs11/Secmod/JksSetPrivateKey.java > Passed: sun/security/pkcs11/Secmod/LoadKeystore.java > Passed: sun/security/pkcs11/Secmod/TestNssDbSqlite.java > Passed: sun/security/pkcs11/Secmod/TrustAnchors.java > Passed: sun/security/pkcs11/SecureRandom/Basic.java > Passed: sun/security/pkcs11/SecureRandom/TestDeserialization.java > Passed: sun/security/pkcs11/Serialize/SerializeProvider.java > Passed: sun/security/pkcs11/Signature/ByteBuffers.java > Passed: sun/security/pkcs11/Signature/ReinitSignature.java > Passed: sun/security/pkcs11/Signature/TestDSA.java > Passed: sun/security/pkcs11/Signature/TestDSAKeyLength.java > Passed: sun/security/pkcs11/Signature/TestRSAKeyLength.java > Passed: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java > FAILED: sun/security/pkcs11/tls/TestKeyMaterial.java > Passed: sun/security/pkcs11/tls/TestLeadingZeroesP11.java > Passed: sun/security/pkcs11/tls/TestMasterSecret.java > Passed: sun/security/pkcs11/tls/TestPremaster.java > Passed: sun/security/pkcs11/tls/TestPRF.java > Passed: sun/security/pkcs11/tls/TestTLS12.java > Passed: sun/security/pkcs11/SampleTest.java > Test results: passed: 70; failed: 3 > > NOTE: failing testcases were already failing on an unpatched JDK. > > Look forward to your answer. > > Kind regards, > Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Fri Jul 27 04:14:18 2018 From: mbalao at redhat.com (Martin Balao) Date: Fri, 27 Jul 2018 01:14:18 -0300 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <75bdd4b5-1143-958e-dd19-a39a5e120d17@oracle.com> References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> <75bdd4b5-1143-958e-dd19-a39a5e120d17@oracle.com> Message-ID: Hi, That's correct: TestTLS12.java was introduced by this patch and is checking that the new feature (TLS 1.2 + SunPKCS11) is working correctly. If the PKCS11 library does not support TLS 1.2 mechanisms, the test must fail. This test should be skipped on those configurations. Kind regards, Martin.- On Thu, Jul 26, 2018 at 7:44 PM, Valerie Peng wrote: > > Update: I submitted your webrev.05 through Mach5, there are one test > failure observed on 4 configurations, all are due to the regression test > TestTLS12.java. It looks like the test fails when the underlying PKCS11 > library does not support the corresponding TLS 12 mechanisms (stacktrace > included as below) > > jib > STDERR: > jib > java.security.ProviderException: Could not generate key > jib > at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsMasterSecretGenerator.engineGenerateKey(P11TlsMasterSecretGenerator.java:181) > jib > at java.base/javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:563) > jib > at TestTLS12.testTlsAuthenticationCodeGeneration(TestTLS12.java:181) > jib > at TestTLS12.main(TestTLS12.java:104) > jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > jib > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > jib > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > jib > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) > jib > at java.base/java.lang.Thread.run(Thread.java:834) > jib > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_MECHANISM_INVALID > jib > at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_DeriveKey(Native Method) > jib > at jdk.crypto.cryptoki/sun.security.pkcs11.P11TlsMasterSecretGenerator.engineGenerateKey(P11TlsMasterSecretGenerator.java:167) > jib > ... 9 more > jib > > jib > JavaTest Message: Test threw exception: java.security.ProviderException: Could not generate key > jib > JavaTest Message: shutting down test > jib > > jib > STATUS:Failed.`main' threw exception: java.security.ProviderException: Could not generate key > > Thanks, > Valerie > > > On 7/23/2018 9:50 PM, Martin Balao wrote: > > Hi Valerie, > > Webrev 05: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.05/ > * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/ > 8029661.webrev.05.zip > > New in Webrev 05: > > * Explicitly casted prfHashMechanism to CK_MECHANISM_TYPE type to avoid > building warning on some compilers (it's a long -> unsigned long cast). > > Regression tests result for jdk/sun/security/pkcs11 category: > > Passed: sun/security/pkcs11/Cipher/JNICheck.java > Passed: sun/security/pkcs11/Cipher/ReinitCipher.java > Passed: sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java > Passed: sun/security/pkcs11/Cipher/TestRawRSACipher.java > Passed: sun/security/pkcs11/Cipher/TestRSACipher.java > Passed: sun/security/pkcs11/Cipher/TestRSACipherWrap.java > Passed: sun/security/pkcs11/Cipher/TestSymmCiphers.java > Passed: sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java > Passed: sun/security/pkcs11/Config/ReadConfInUTF16Env.sh > Passed: sun/security/pkcs11/ec/ReadCertificates.java > Passed: sun/security/pkcs11/ec/ReadPKCS12.java > Passed: sun/security/pkcs11/ec/TestCurves.java > Passed: sun/security/pkcs11/ec/TestECDH.java > Passed: sun/security/pkcs11/ec/TestECDH2.java > Passed: sun/security/pkcs11/ec/TestECDSA.java > Passed: sun/security/pkcs11/ec/TestECDSA2.java > Passed: sun/security/pkcs11/ec/TestECGenSpec.java > FAILED: sun/security/pkcs11/ec/TestKeyFactory.java > Passed: sun/security/pkcs11/fips/ClientJSSEServerJSSE.java > Passed: sun/security/pkcs11/fips/TrustManagerTest.java > Passed: sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java > Passed: sun/security/pkcs11/KeyAgreement/TestDH.java > Passed: sun/security/pkcs11/KeyAgreement/TestInterop.java > Passed: sun/security/pkcs11/KeyAgreement/TestShort.java > Passed: sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java > Passed: sun/security/pkcs11/KeyGenerator/DESParity.java > Passed: sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java > Passed: sun/security/pkcs11/KeyPairGenerator/TestDH2048.java > Passed: sun/security/pkcs11/KeyStore/Basic.sh > Passed: sun/security/pkcs11/KeyStore/ClientAuth.sh > Passed: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh > Passed: sun/security/pkcs11/KeyStore/Solaris.sh > Passed: sun/security/pkcs11/Mac/MacKAT.java > Passed: sun/security/pkcs11/Mac/MacSameTest.java > Passed: sun/security/pkcs11/Mac/ReinitMac.java > Passed: sun/security/pkcs11/MessageDigest/ByteBuffers.java > Passed: sun/security/pkcs11/MessageDigest/DigestKAT.java > Passed: sun/security/pkcs11/MessageDigest/ReinitDigest.java > Passed: sun/security/pkcs11/MessageDigest/TestCloning.java > Passed: sun/security/pkcs11/Provider/Absolute.java > Passed: sun/security/pkcs11/Provider/ConfigQuotedString.sh > Passed: sun/security/pkcs11/Provider/ConfigShortPath.java > Passed: sun/security/pkcs11/Provider/Login.sh > Passed: sun/security/pkcs11/Provider/LoginISE.java > Passed: sun/security/pkcs11/rsa/KeyWrap.java > Passed: sun/security/pkcs11/rsa/TestCACerts.java > Passed: sun/security/pkcs11/rsa/TestKeyFactory.java > Passed: sun/security/pkcs11/rsa/TestKeyPairGenerator.java > Passed: sun/security/pkcs11/rsa/TestSignatures.java > Passed: sun/security/pkcs11/Secmod/AddPrivateKey.java > FAILED: sun/security/pkcs11/Secmod/AddTrustedCert.java > Passed: sun/security/pkcs11/Secmod/Crypto.java > Passed: sun/security/pkcs11/Secmod/GetPrivateKey.java > Passed: sun/security/pkcs11/Secmod/JksSetPrivateKey.java > Passed: sun/security/pkcs11/Secmod/LoadKeystore.java > Passed: sun/security/pkcs11/Secmod/TestNssDbSqlite.java > Passed: sun/security/pkcs11/Secmod/TrustAnchors.java > Passed: sun/security/pkcs11/SecureRandom/Basic.java > Passed: sun/security/pkcs11/SecureRandom/TestDeserialization.java > Passed: sun/security/pkcs11/Serialize/SerializeProvider.java > Passed: sun/security/pkcs11/Signature/ByteBuffers.java > Passed: sun/security/pkcs11/Signature/ReinitSignature.java > Passed: sun/security/pkcs11/Signature/TestDSA.java > Passed: sun/security/pkcs11/Signature/TestDSAKeyLength.java > Passed: sun/security/pkcs11/Signature/TestRSAKeyLength.java > Passed: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java > FAILED: sun/security/pkcs11/tls/TestKeyMaterial.java > Passed: sun/security/pkcs11/tls/TestLeadingZeroesP11.java > Passed: sun/security/pkcs11/tls/TestMasterSecret.java > Passed: sun/security/pkcs11/tls/TestPremaster.java > Passed: sun/security/pkcs11/tls/TestPRF.java > Passed: sun/security/pkcs11/tls/TestTLS12.java > Passed: sun/security/pkcs11/SampleTest.java > Test results: passed: 70; failed: 3 > > NOTE: failing testcases were already failing on an unpatched JDK. > > Look forward to your answer. > > Kind regards, > Martin.- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Jul 27 15:29:35 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 27 Jul 2018 16:29:35 +0100 Subject: RFR: 8207775: Better management of CipherCore buffers In-Reply-To: References: Message-ID: <64125402-3d3f-59b9-9253-9003b0b7676b@oracle.com> Thanks Tony. If it's alright with you, I'd like to make one more edit for this change. http://cr.openjdk.java.net/~coffeys/webrev.8207775.v2/webrev/ There's a condition where we can null out an array early if we're returning a copy. See lines 671-683 Regards, Sean. On 26/07/18 17:42, Anthony Scarpino wrote: > On 07/26/2018 07:36 AM, Se?n Coffey wrote: >> https://bugs.openjdk.java.net/browse/JDK-8207775 >> >> Simple enough fix to null out some internal buffers once they're no >> longer required. >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/ >> >> regards, >> Sean. >> > > that looks fine.. > > Tony From anthony.scarpino at oracle.com Fri Jul 27 20:02:43 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 27 Jul 2018 13:02:43 -0700 Subject: RFR: 8207775: Better management of CipherCore buffers In-Reply-To: <64125402-3d3f-59b9-9253-9003b0b7676b@oracle.com> References: <64125402-3d3f-59b9-9253-9003b0b7676b@oracle.com> Message-ID: <080200b7-ce2e-76cb-763e-3e934f05aaaf@oracle.com> If we are going to add more, here are two more ton consider: - It looks like there is another Arrays.copyOf() on doFinal() line 851 - doFinal() at line 897 there might be something that should be done with 'buffer'. In particular as a result of line 963's arraycopy(). Tony On 07/27/2018 08:29 AM, Se?n Coffey wrote: > Thanks Tony. If it's alright with you, I'd like to make one more edit > for this change. > > http://cr.openjdk.java.net/~coffeys/webrev.8207775.v2/webrev/ > > There's a condition where we can null out an array early if we're > returning a copy. See lines 671-683 > > Regards, > Sean. > > On 26/07/18 17:42, Anthony Scarpino wrote: >> On 07/26/2018 07:36 AM, Se?n Coffey wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8207775 >>> >>> Simple enough fix to null out some internal buffers once they're no >>> longer required. >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/ >>> >>> regards, >>> Sean. >>> >> >> that looks fine.. >> >> Tony > From xuelei.fan at oracle.com Mon Jul 30 16:59:57 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Jul 2018 09:59:57 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received Message-ID: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> Hi, Please review the update for the TLS 1.3 half-close and synchronization implementation: http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ Unlike TLS 1.2 and prior versions, for TLS 1.3, the close_notify is use to close the local write side and peer read side only. After the close_notify get handles, the local read side and peer write side may still be open. In this update, if an application calls SSLEngine.closeInbound/Outbound() or SSLSocket.shutdownInput/Output(), half-close will be used. For compatibility, if SSLSocket.close() get called, a duplex close will be tried. In order to support duplex close, JDK will use the user_canceled warning alert even the handshake complete. In practice, an application may only close outbound even it is intended to close the inbound as well, or close the connection completely. It works for TLS 1.2 and prior versions. But no more for TLS 1.3 because of the close_notify behavior change in the TLS 1.3 specification. The application may be hung and dead-waiting for read/close. It could be solved by closing the inbound explicitly. In order to mitigate the impact, a new System Property is introduced, "jdk.tls.acknowledgeCloseNotify" if source code update is not available. If the System Property is set to "true", if receiving the close_notify, a close_notify alert will be responded. It is a countermeasure of the TLS 1.3 half-close issues. Thanks, Xuelei From xuelei.fan at oracle.com Mon Jul 30 17:24:45 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Jul 2018 10:24:45 -0700 Subject: Code Review Request, JDK-8207009 SSLEngine#closeInbound mentions SSLException when no close_notify is received In-Reply-To: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> References: <99d6eeaf-f77b-1967-10be-92347273b794@oracle.com> Message-ID: Please let me know your concerns by the end of August 1st, 2018. Thanks, Xuelei On 7/30/2018 9:59 AM, Xuelei Fan wrote: > Hi, > > Please review the update for the TLS 1.3 half-close and synchronization > implementation: > ?? http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/ > > Unlike TLS 1.2 and prior versions, for TLS 1.3, the close_notify is use > to close the local write side and peer read side only.? After the > close_notify get handles, the local read side and peer write side may > still be open. > > In this update, if an application calls > SSLEngine.closeInbound/Outbound() or SSLSocket.shutdownInput/Output(), > half-close will be used.? For compatibility, if SSLSocket.close() get > called, a duplex close will be tried.? In order to support duplex close, > JDK will use the user_canceled warning alert even the handshake complete. > > In practice, an application may only close outbound even it is intended > to close the inbound as well, or close the connection completely.? It > works for TLS 1.2 and prior versions.? But no more for TLS 1.3 because > of the close_notify behavior change in the TLS 1.3 specification.? The > application may be hung and dead-waiting for read/close.? It could be > solved by closing the inbound explicitly.? In order to mitigate the > impact, a new System Property is introduced, > "jdk.tls.acknowledgeCloseNotify" if source code update is not available. > ?If the System Property is set to "true", if receiving the > close_notify, a close_notify alert will be responded.? It is a > countermeasure of the TLS 1.3 half-close issues. > > Thanks, > Xuelei > > > From xuelei.fan at oracle.com Mon Jul 30 17:57:10 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Jul 2018 10:57:10 -0700 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> Message-ID: Hi Norman, Would you mind look at the code I posted in the following thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html I appreciate if you could have a test by the end of this week. Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" as a workaround. Thanks, Xuelei On 7/25/2018 11:22 PM, Norman Maurer wrote: > Just FYI? I tested this patch via the netty ssl tests and we no longer > see the class-cast-exception problems I reported before dso I think this > solves the issue. > > > That said we still encounter a few test-failures for tests that test > behaviour of closing outbound of the SSLEngine but I think these are > more related to > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html?and > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html?. > > Bye > Norman > > > >> On 25. Jul 2018, at 20:30, Xuelei Fan > > wrote: >> >> Hi, >> >> Please review the update for JDK-8208166: >> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8208166 >> >> Thanks, >> Xuelei > From norman.maurer at googlemail.com Mon Jul 30 18:06:37 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 30 Jul 2018 20:06:37 +0200 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> Message-ID: <4569EC59-19FA-4392-9C8F-1D6EE16395FD@googlemail.com> Will do and report back as soon as possible. Thanks Norman > On 30. Jul 2018, at 19:57, Xuelei Fan wrote: > > Hi Norman, > > Would you mind look at the code I posted in the following thread: > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html > > I appreciate if you could have a test by the end of this week. > > Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" as a workaround. > > Thanks, > Xuelei > > On 7/25/2018 11:22 PM, Norman Maurer wrote: >> Just FYI? I tested this patch via the netty ssl tests and we no longer see the class-cast-exception problems I reported before dso I think this solves the issue. >> That said we still encounter a few test-failures for tests that test behaviour of closing outbound of the SSLEngine but I think these are more related to http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html and http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html . >> Bye >> Norman >>> On 25. Jul 2018, at 20:30, Xuelei Fan > wrote: >>> >>> Hi, >>> >>> Please review the update for JDK-8208166: >>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8208166 >>> >>> Thanks, >>> Xuelei From xuelei.fan at oracle.com Mon Jul 30 18:08:39 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Jul 2018 11:08:39 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> Message-ID: Hi Simone, Would you mind look at the code I posted in the following thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html I'm trying to address the close concerns of yours. I appreciate if you could comment by the end of this week. Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" System Property as a workaround. Thanks, Xuelei On 7/13/2018 9:19 AM, Simone Bordet wrote: > Hi, > > On Fri, Jul 13, 2018 at 3:45 PM Xuelei Fan wrote: >> Thank you very much, Simone. I find at least two improvements we can >> take. It's really good! > > Great! > > Let know when they land in a 11+X release and we'll try them out. > > Thanks! > From xuelei.fan at oracle.com Mon Jul 30 18:13:59 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Jul 2018 11:13:59 -0700 Subject: Inconsistent SSLEngine behavior for closing outbound while in handshake in 11ea22 In-Reply-To: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> References: <8E8BF574-DA2B-435E-A02C-5EB7AC832D13@fastmail.com> Message-ID: <76b451f1-c161-b9ac-8c53-a5a0dbe3c645@oracle.com> Hi Tim, Would you mind look at the code I posted in the following thread: http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html In the update, we are trying make the synchronization more simple and robust. I appreciate if you could comment by the end of this week. Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way because TLS 1.2 and prior version can work around it. But for TLS 1.3, it is possible to hang the application if the connection is not closed. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" System Property as a workaround. Thanks, Xuelei On 7/18/2018 11:51 AM, Tim Brooks wrote: > Yes. I can test once there is a patch. My inquiry was motivated by some > work on Elasticsearch fyi. I can test a patch against that work. > > https://github.com/elastic/elasticsearch/issues/32144 > > - Tim > >> On Jul 17, 2018, at 8:40 PM, Xuelei Fan > > wrote: >> >> Hi, >> >> We are working on the JDK 11 close issue. >> https://bugs.openjdk.java.net/browse/JDK-8207009 >> >> I appreciate if you can help test if we have a patch. >> >> Thanks, >> Xuelei >> >> On 7/17/2018 4:26 PM, Tim Brooks wrote: >>> My understanding is that when you are interested in closing the >>> underlying socket when using the SSLEngine, you must call >>> closeOutbound() and WRAP and UNWRAP until both isInboundDone() and >>> isOutboundDone() return true. >>> One edge case of this is if you are interested in closing the socket >>> prior to the completion of a handshake. In JDK 10.0.1 (and I believe >>> prior JDKs) this was the behavior for one way in which this arises: >>> 1. Initiate handshake >>> 2. UNWRAP data from client >>> 3. WRAP data to send to client. Handshake status is "NEED_UNWRAP" >>> 4. Call closeOutbound() (perhaps the server is shutting down and you >>> want to close the connection). >>> 5. Handshake status now returns "NEED_WRAP" >>> JDK10: >>> isInboundDone() - returns false >>> isOutboundDone() - returns false >>> A call to wrap() produces 7 bytes and status = CLOSED. Handshake >>> status is now NEED_UNWRAP. >>> isInboundDone() - returns false >>> isOutboundDone() - returns true >>> JDK11: >>> isInboundDone() - returns true >>> isOutboundDone() - returns false >>> A call to wrap() throws the following exception: >>> javax.net.ssl.SSLException: Cannot kickstart, the connection is >>> broken or closed >>> at >>> java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:205) >>> at >>> java.base/sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:167) >>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:138) >>> at java.base/sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:116) >>> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471) >>> I?m not sure what the procedure for closing a connection prior to >>> handshake completion is for TLS. But obviously this is a scenario >>> that can arise. It seems wrong to me that the state transitions for >>> the SSLEngine do not handle this. The fact that ?isOutboundDone()? >>> returns false, but I cannot WRAP seems to be an issue. > From norman.maurer at googlemail.com Mon Jul 30 19:54:36 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 30 Jul 2018 21:54:36 +0200 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: <4569EC59-19FA-4392-9C8F-1D6EE16395FD@googlemail.com> References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> <4569EC59-19FA-4392-9C8F-1D6EE16395FD@googlemail.com> Message-ID: Hey Xuelei, I just re-ran our testsuite with your patch and everything pass except two tests. After digging a bit I found that we needed to add explicit calls to `SSLEngine.setUSeClientMode(false)` now in these test where we did not need to do this before. The tests in question are: https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400 https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418 Here we use SslContext.getDefault().createSSLEngine() and did not set the mode explicitly before. With the following patch to netty all works when using your patch: diff --git a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java index e982b6a63..40d6e7b59 100644 --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java @@ -398,7 +398,9 @@ public class SslHandlerTest { @Test public void testCloseFutureNotified() throws Exception { - SslHandler handler = new SslHandler(SSLContext.getDefault().createSSLEngine()); + SSLEngine engine = SSLContext.getDefault().createSSLEngine(); + engine.setUseClientMode(false); + SslHandler handler = new SslHandler(engine); EmbeddedChannel ch = new EmbeddedChannel(handler); ch.close(); @@ -417,6 +419,7 @@ public class SslHandlerTest { @Test(timeout = 5000) public void testEventsFired() throws Exception { SSLEngine engine = SSLContext.getDefault().createSSLEngine(); + engine.setUseClientMode(false); final BlockingQueue events = new LinkedBlockingQueue(); EmbeddedChannel channel = new EmbeddedChannel(new SslHandler(engine), new ChannelInboundHandlerAdapter() { @Override The exception we see without the patch is: java.lang.IllegalStateException: Client/Server mode has not yet been set. at java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98) at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731) at io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644) at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634) at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235) at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409) at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396) at io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203) at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115) at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107) at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) at io.netty.channel.DefaultChannelPipeline.access$000(DefaultChannelPipeline.java:46) at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1487) at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1161) at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:686) at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:510) at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:476) at io.netty.channel.embedded.EmbeddedChannel$EmbeddedUnsafe$1.register(EmbeddedChannel.java:773) at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:130) at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:124) at io.netty.channel.embedded.EmbeddedChannel.setup(EmbeddedChannel.java:208) at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:167) at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:148) at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:135) at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:100) at io.netty.handler.ssl.SslHandlerTest.testCloseFutureNotified(SslHandlerTest.java:404) 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 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) So I have no problem to patch our test-case but I wondered if this may break others in other cases and so is a regression. Let me know what you think. Norman > On 30. Jul 2018, at 20:06, Norman Maurer wrote: > > Will do and report back as soon as possible. > > Thanks > Norman > > >> On 30. Jul 2018, at 19:57, Xuelei Fan wrote: >> >> Hi Norman, >> >> Would you mind look at the code I posted in the following thread: >> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >> >> I appreciate if you could have a test by the end of this week. >> >> Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" as a workaround. >> >> Thanks, >> Xuelei >> >> On 7/25/2018 11:22 PM, Norman Maurer wrote: >>> Just FYI? I tested this patch via the netty ssl tests and we no longer see the class-cast-exception problems I reported before dso I think this solves the issue. >>> That said we still encounter a few test-failures for tests that test behaviour of closing outbound of the SSLEngine but I think these are more related to http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html and http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html . >>> Bye >>> Norman >>>> On 25. Jul 2018, at 20:30, Xuelei Fan > wrote: >>>> >>>> Hi, >>>> >>>> Please review the update for JDK-8208166: >>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8208166 >>>> >>>> Thanks, >>>> Xuelei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.maurer at googlemail.com Mon Jul 30 20:11:12 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 30 Jul 2018 22:11:12 +0200 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> <4569EC59-19FA-4392-9C8F-1D6EE16395FD@googlemail.com> Message-ID: <41082F88-4626-4C64-A922-C697C38C4902@googlemail.com> Sorry but I just noticed we still have a another integration test failing which tests that client SSL renegotiation is failing. This seems to be not the case anymore with java11 + your patch (it was in ea20 tho). https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java Let me know if I need to dig more into it. Bye Norman > On 30. Jul 2018, at 21:54, Norman Maurer wrote: > > Hey Xuelei, > > I just re-ran our testsuite with your patch and everything pass except two tests. After digging a bit I found that we needed to add explicit calls to `SSLEngine.setUSeClientMode(false)` now in these test where we did not need to do this before. > > The tests in question are: > > https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400 > https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418 > > Here we use SslContext.getDefault().createSSLEngine() and did not set the mode explicitly before. With the following patch to netty all works when using your patch: > > diff --git a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java > index e982b6a63..40d6e7b59 100644 > --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java > +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java > @@ -398,7 +398,9 @@ public class SslHandlerTest { > > @Test > public void testCloseFutureNotified() throws Exception { > - SslHandler handler = new SslHandler(SSLContext.getDefault().createSSLEngine()); > + SSLEngine engine = SSLContext.getDefault().createSSLEngine(); > + engine.setUseClientMode(false); > + SslHandler handler = new SslHandler(engine); > EmbeddedChannel ch = new EmbeddedChannel(handler); > > ch.close(); > @@ -417,6 +419,7 @@ public class SslHandlerTest { > @Test(timeout = 5000) > public void testEventsFired() throws Exception { > SSLEngine engine = SSLContext.getDefault().createSSLEngine(); > + engine.setUseClientMode(false); > final BlockingQueue events = new LinkedBlockingQueue(); > EmbeddedChannel channel = new EmbeddedChannel(new SslHandler(engine), new ChannelInboundHandlerAdapter() { > @Override > > > The exception we see without the patch is: > > java.lang.IllegalStateException: Client/Server mode has not yet been set. > at java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98) > at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731) > at io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644) > at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634) > at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) > at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235) > at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409) > at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396) > at io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203) > at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115) > at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107) > at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) > at io.netty.channel.DefaultChannelPipeline.access$000(DefaultChannelPipeline.java:46) > at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1487) > at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1161) > at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:686) > at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:510) > at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:476) > at io.netty.channel.embedded.EmbeddedChannel$EmbeddedUnsafe$1.register(EmbeddedChannel.java:773) > at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:130) > at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:124) > at io.netty.channel.embedded.EmbeddedChannel.setup(EmbeddedChannel.java:208) > at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:167) > at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:148) > at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:135) > at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:100) > at io.netty.handler.ssl.SslHandlerTest.testCloseFutureNotified(SslHandlerTest.java:404) > 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 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) > at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > > > So I have no problem to patch our test-case but I wondered if this may break others in other cases and so is a regression. > > Let me know what you think. > Norman > >> On 30. Jul 2018, at 20:06, Norman Maurer > wrote: >> >> Will do and report back as soon as possible. >> >> Thanks >> Norman >> >> >>> On 30. Jul 2018, at 19:57, Xuelei Fan > wrote: >>> >>> Hi Norman, >>> >>> Would you mind look at the code I posted in the following thread: >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>> >>> I appreciate if you could have a test by the end of this week. >>> >>> Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" as a workaround. >>> >>> Thanks, >>> Xuelei >>> >>> On 7/25/2018 11:22 PM, Norman Maurer wrote: >>>> Just FYI? I tested this patch via the netty ssl tests and we no longer see the class-cast-exception problems I reported before dso I think this solves the issue. >>>> That said we still encounter a few test-failures for tests that test behaviour of closing outbound of the SSLEngine but I think these are more related to http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html and http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html . >>>> Bye >>>> Norman >>>>> On 25. Jul 2018, at 20:30, Xuelei Fan > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the update for JDK-8208166: >>>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8208166 >>>>> >>>>> Thanks, >>>>> Xuelei >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Jul 30 20:13:48 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Jul 2018 13:13:48 -0700 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> <4569EC59-19FA-4392-9C8F-1D6EE16395FD@googlemail.com> Message-ID: Hi Norman, Thank you very much for the great help! Glad to know it works for you. For the SSLEngine.setUSeClientMode() issues, the SSLEngine.beginHandshake() spec is expected to throw IllegalStateException if the client/server mode has not yet been set. https://docs.oracle.com/javase/10/docs/api/index.html?overview-summary.html I will make more evaluation about this behavior change. Thanks, Xuelei On 7/30/2018 12:54 PM, Norman Maurer wrote: > Hey?Xuelei, > > I just re-ran our testsuite with your patch and everything pass except > two tests. After digging a bit I found that we needed to add explicit > calls to `SSLEngine.setUSeClientMode(false)` now in these test where we > did not need to do this before. > > The tests in question are: > > https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400 > https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418 > > Here we use SslContext.getDefault().createSSLEngine() and did not set > the mode explicitly before. With the following patch to netty all works > when using your patch: > > diff --git > a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java > b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java > index e982b6a63..40d6e7b59 100644 > --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java > +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java > @@ -398,7 +398,9 @@ public class SslHandlerTest { > ? ? ?@Test > ? ? ?public void testCloseFutureNotified() throws Exception { > - ? ? ? ?SslHandler handler = new > SslHandler(SSLContext.getDefault().createSSLEngine()); > + ? ? ? ?SSLEngine engine = SSLContext.getDefault().createSSLEngine(); > + ? ? ? ?engine.setUseClientMode(false); > + ? ? ? ?SslHandler handler = new SslHandler(engine); > ? ? ? ? ?EmbeddedChannel ch = new EmbeddedChannel(handler); > ? ? ? ? ?ch.close(); > @@ -417,6 +419,7 @@ public class SslHandlerTest { > ? ? ?@Test(timeout = 5000) > ? ? ?public void testEventsFired() throws Exception { > ? ? ? ? ?SSLEngine engine = SSLContext.getDefault().createSSLEngine(); > + ? ? ? ?engine.setUseClientMode(false); > ? ? ? ? ?final BlockingQueue events = new > LinkedBlockingQueue(); > ? ? ? ? ?EmbeddedChannel channel = new EmbeddedChannel(new > SslHandler(engine), new ChannelInboundHandlerAdapter() { > ? ? ? ? ? ? ?@Override > > > The exception we see without the patch is: > > java.lang.IllegalStateException: Client/Server mode has not yet been set. > at > java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98) > at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731) > at > io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644) > at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634) > at > io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) > at > io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235) > at > io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409) > at > io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396) > at > io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203) > at > io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115) > at > io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107) > at > io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) > at > io.netty.channel.DefaultChannelPipeline.access$000(DefaultChannelPipeline.java:46) > at > io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1487) > at > io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1161) > at > io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:686) > at > io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:510) > at > io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:476) > at > io.netty.channel.embedded.EmbeddedChannel$EmbeddedUnsafe$1.register(EmbeddedChannel.java:773) > at > io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:130) > at > io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:124) > at io.netty.channel.embedded.EmbeddedChannel.setup(EmbeddedChannel.java:208) > at > io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:167) > at > io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:148) > at > io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:135) > at > io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:100) > at > io.netty.handler.ssl.SslHandlerTest.testCloseFutureNotified(SslHandlerTest.java:404) > 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 > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at > com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at > com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) > at > com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > > > So I have no problem to patch our test-case but I wondered if this may > break others in other cases and so is a regression. > > Let me know what you think. > Norman > >> On 30. Jul 2018, at 20:06, Norman Maurer > > wrote: >> >> Will do and report back as soon as possible. >> >> Thanks >> Norman >> >> >>> On 30. Jul 2018, at 19:57, Xuelei Fan >> > wrote: >>> >>> Hi Norman, >>> >>> Would you mind look at the code I posted in the following thread: >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>> >>> I appreciate if you could have a test by the end of this week. >>> >>> Note that with this update, a complete TLS connection should close >>> both inbound and outbound explicitly. ?However, existing applications >>> may not did this way. ?If the source code update is not available, >>> please consider to use the "jdk.tls.acknowledgeCloseNotify" as a >>> workaround. >>> >>> Thanks, >>> Xuelei >>> >>> On 7/25/2018 11:22 PM, Norman Maurer wrote: >>>> Just FYI? I tested this patch via the netty ssl tests and we no >>>> longer see the class-cast-exception problems I reported before dso I >>>> think this solves the issue. >>>> That said we still encounter a few test-failures for tests that test >>>> behaviour of closing outbound of the SSLEngine but I think these are >>>> more related to >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html >>>> and >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html >>>> . >>>> Bye >>>> Norman >>>>> On 25. Jul 2018, at 20:30, Xuelei Fan >>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the update for JDK-8208166: >>>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8208166 >>>>> >>>>> Thanks, >>>>> Xuelei >> > From xuelei.fan at oracle.com Mon Jul 30 20:23:38 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Jul 2018 13:23:38 -0700 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: <41082F88-4626-4C64-A922-C697C38C4902@googlemail.com> References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> <4569EC59-19FA-4392-9C8F-1D6EE16395FD@googlemail.com> <41082F88-4626-4C64-A922-C697C38C4902@googlemail.com> Message-ID: Would you mind send me the debug log (-Djavax.net.debug=all) and the exception stacks? The "renegotiation" in TLS 1.3 is different from TLS 1.2 and prior specifications. It would be helpful to me to find the cause of the test failure. Thanks, Xuelei On 7/30/2018 1:11 PM, Norman Maurer wrote: > Sorry but I just noticed we still have a another integration test > failing which tests that client SSL renegotiation is failing. This seems > to be not the case anymore with java11 + your patch (it was in ea20 tho). > > https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java > > > Let me know if I need to dig more into it. > > Bye > Norman > > >> On 30. Jul 2018, at 21:54, Norman Maurer > > wrote: >> >> Hey?Xuelei, >> >> I just re-ran our testsuite with your patch and everything pass except >> two tests. After digging a bit I found that we needed to add explicit >> calls to `SSLEngine.setUSeClientMode(false)` now in these test where >> we did not need to do this before. >> >> The tests in question are: >> >> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400 >> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418 >> >> Here we use SslContext.getDefault().createSSLEngine() and did not set >> the mode explicitly before. With the following patch to netty all >> works when using your patch: >> >> diff --git >> a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >> b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >> index e982b6a63..40d6e7b59 100644 >> --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >> +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >> @@ -398,7 +398,9 @@ public class SslHandlerTest { >> ? ? ?@Test >> ? ? ?public void testCloseFutureNotified() throws Exception { >> - ? ? ? ?SslHandler handler = new >> SslHandler(SSLContext.getDefault().createSSLEngine()); >> + ? ? ? ?SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >> + ? ? ? ?engine.setUseClientMode(false); >> + ? ? ? ?SslHandler handler = new SslHandler(engine); >> ? ? ? ? ?EmbeddedChannel ch = new EmbeddedChannel(handler); >> ? ? ? ? ?ch.close(); >> @@ -417,6 +419,7 @@ public class SslHandlerTest { >> ? ? ?@Test(timeout = 5000) >> ? ? ?public void testEventsFired() throws Exception { >> ? ? ? ? ?SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >> + ? ? ? ?engine.setUseClientMode(false); >> ? ? ? ? ?final BlockingQueue events = new >> LinkedBlockingQueue(); >> ? ? ? ? ?EmbeddedChannel channel = new EmbeddedChannel(new >> SslHandler(engine), new ChannelInboundHandlerAdapter() { >> ? ? ? ? ? ? ?@Override >> >> >> The exception we see without the patch is: >> >> java.lang.IllegalStateException: Client/Server mode has not yet been set. >> at >> java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98) >> at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731) >> at >> io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644) >> at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634) >> at >> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) >> at >> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235) >> at >> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409) >> at >> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396) >> at >> io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203) >> at >> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115) >> at >> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107) >> at >> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) >> at >> io.netty.channel.DefaultChannelPipeline.access$000(DefaultChannelPipeline.java:46) >> at >> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1487) >> at >> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1161) >> at >> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:686) >> at >> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:510) >> at >> io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:476) >> at >> io.netty.channel.embedded.EmbeddedChannel$EmbeddedUnsafe$1.register(EmbeddedChannel.java:773) >> at >> io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:130) >> at >> io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:124) >> at >> io.netty.channel.embedded.EmbeddedChannel.setup(EmbeddedChannel.java:208) >> at >> io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:167) >> at >> io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:148) >> at >> io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:135) >> at >> io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:100) >> at >> io.netty.handler.ssl.SslHandlerTest.testCloseFutureNotified(SslHandlerTest.java:404) >> 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 >> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >> at >> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >> at >> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >> at >> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >> at >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >> at >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >> at org.junit.runner.JUnitCore.run(JUnitCore.java:137) >> at >> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) >> at >> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) >> at >> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) >> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) >> >> >> So I have no problem to patch our test-case but I wondered if this may >> break others in other cases and so is a regression. >> >> Let me know what you think. >> Norman >> >>> On 30. Jul 2018, at 20:06, Norman Maurer >>> > >>> wrote: >>> >>> Will do and report back as soon as possible. >>> >>> Thanks >>> Norman >>> >>> >>>> On 30. Jul 2018, at 19:57, Xuelei Fan >>> > wrote: >>>> >>>> Hi Norman, >>>> >>>> Would you mind look at the code I posted in the following thread: >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>>> >>>> I appreciate if you could have a test by the end of this week. >>>> >>>> Note that with this update, a complete TLS connection should close >>>> both inbound and outbound explicitly. ?However, existing >>>> applications may not did this way. ?If the source code update is not >>>> available, please consider to use the >>>> "jdk.tls.acknowledgeCloseNotify" as a workaround. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 7/25/2018 11:22 PM, Norman Maurer wrote: >>>>> Just FYI? I tested this patch via the netty ssl tests and we no >>>>> longer see the class-cast-exception problems I reported before dso >>>>> I think this solves the issue. >>>>> That said we still encounter a few test-failures for tests that >>>>> test behaviour of closing outbound of the SSLEngine but I think >>>>> these are more related to >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html >>>>> and >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html >>>>> . >>>>> Bye >>>>> Norman >>>>>> On 25. Jul 2018, at 20:30, Xuelei Fan >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the update for JDK-8208166: >>>>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ >>>>>> >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8208166 >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>> >> > From norman.maurer at googlemail.com Tue Jul 31 05:19:34 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Tue, 31 Jul 2018 07:19:34 +0200 Subject: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029 In-Reply-To: References: <5157fccf-f9e0-2dcb-33f0-8927b7b0855e@oracle.com> <4569EC59-19FA-4392-9C8F-1D6EE16395FD@googlemail.com> <41082F88-4626-4C64-A922-C697C38C4902@googlemail.com> Message-ID: <5DE48751-A893-4E0A-8F26-DAC64493101F@googlemail.com> After digging more this morning I noticed the test code did made some wrong assumptions which just worked out of luck before. After fixing the test everything passes now. So +1 from me on the patch :) Also sorry for the false-alarm. Niorman > On 30. Jul 2018, at 22:23, Xuelei Fan wrote: > > Would you mind send me the debug log (-Djavax.net.debug=all) and the exception stacks? The "renegotiation" in TLS 1.3 is different from TLS 1.2 and prior specifications. It would be helpful to me to find the cause of the test failure. > > Thanks, > Xuelei > > On 7/30/2018 1:11 PM, Norman Maurer wrote: >> Sorry but I just noticed we still have a another integration test failing which tests that client SSL renegotiation is failing. This seems to be not the case anymore with java11 + your patch (it was in ea20 tho). >> https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java >> Let me know if I need to dig more into it. >> Bye >> Norman >>> On 30. Jul 2018, at 21:54, Norman Maurer > wrote: >>> >>> Hey Xuelei, >>> >>> I just re-ran our testsuite with your patch and everything pass except two tests. After digging a bit I found that we needed to add explicit calls to `SSLEngine.setUSeClientMode(false)` now in these test where we did not need to do this before. >>> >>> The tests in question are: >>> >>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400 >>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418 >>> >>> Here we use SslContext.getDefault().createSSLEngine() and did not set the mode explicitly before. With the following patch to netty all works when using your patch: >>> >>> diff --git a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >>> index e982b6a63..40d6e7b59 100644 >>> --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >>> +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java >>> @@ -398,7 +398,9 @@ public class SslHandlerTest { >>> @Test >>> public void testCloseFutureNotified() throws Exception { >>> - SslHandler handler = new SslHandler(SSLContext.getDefault().createSSLEngine()); >>> + SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >>> + engine.setUseClientMode(false); >>> + SslHandler handler = new SslHandler(engine); >>> EmbeddedChannel ch = new EmbeddedChannel(handler); >>> ch.close(); >>> @@ -417,6 +419,7 @@ public class SslHandlerTest { >>> @Test(timeout = 5000) >>> public void testEventsFired() throws Exception { >>> SSLEngine engine = SSLContext.getDefault().createSSLEngine(); >>> + engine.setUseClientMode(false); >>> final BlockingQueue events = new LinkedBlockingQueue(); >>> EmbeddedChannel channel = new EmbeddedChannel(new SslHandler(engine), new ChannelInboundHandlerAdapter() { >>> @Override >>> >>> >>> The exception we see without the patch is: >>> >>> java.lang.IllegalStateException: Client/Server mode has not yet been set. >>> at java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98) >>> at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731) >>> at io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644) >>> at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634) >>> at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) >>> at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235) >>> at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409) >>> at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396) >>> at io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203) >>> at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115) >>> at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107) >>> at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637) >>> at io.netty.channel.DefaultChannelPipeline.access$000(DefaultChannelPipeline.java:46) >>> at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1487) >>> at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1161) >>> at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:686) >>> at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:510) >>> at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:476) >>> at io.netty.channel.embedded.EmbeddedChannel$EmbeddedUnsafe$1.register(EmbeddedChannel.java:773) >>> at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:130) >>> at io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:124) >>> at io.netty.channel.embedded.EmbeddedChannel.setup(EmbeddedChannel.java:208) >>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:167) >>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:148) >>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:135) >>> at io.netty.channel.embedded.EmbeddedChannel.(EmbeddedChannel.java:100) >>> at io.netty.handler.ssl.SslHandlerTest.testCloseFutureNotified(SslHandlerTest.java:404) >>> 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 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >>> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >>> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >>> at org.junit.runner.JUnitCore.run(JUnitCore.java:137) >>> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) >>> at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) >>> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) >>> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) >>> >>> >>> So I have no problem to patch our test-case but I wondered if this may break others in other cases and so is a regression. >>> >>> Let me know what you think. >>> Norman >>> >>>> On 30. Jul 2018, at 20:06, Norman Maurer > wrote: >>>> >>>> Will do and report back as soon as possible. >>>> >>>> Thanks >>>> Norman >>>> >>>> >>>>> On 30. Jul 2018, at 19:57, Xuelei Fan > wrote: >>>>> >>>>> Hi Norman, >>>>> >>>>> Would you mind look at the code I posted in the following thread: >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>>>> >>>>> I appreciate if you could have a test by the end of this week. >>>>> >>>>> Note that with this update, a complete TLS connection should close both inbound and outbound explicitly. However, existing applications may not did this way. If the source code update is not available, please consider to use the "jdk.tls.acknowledgeCloseNotify" as a workaround. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 7/25/2018 11:22 PM, Norman Maurer wrote: >>>>>> Just FYI? I tested this patch via the netty ssl tests and we no longer see the class-cast-exception problems I reported before dso I think this solves the issue. >>>>>> That said we still encounter a few test-failures for tests that test behaviour of closing outbound of the SSLEngine but I think these are more related to http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html and http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html . >>>>>> Bye >>>>>> Norman >>>>>>> On 25. Jul 2018, at 20:30, Xuelei Fan > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Please review the update for JDK-8208166: >>>>>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8208166 >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>> >>> From sean.coffey at oracle.com Tue Jul 31 09:04:11 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 31 Jul 2018 10:04:11 +0100 Subject: RFR: 8207775: Better management of CipherCore buffers In-Reply-To: <080200b7-ce2e-76cb-763e-3e934f05aaaf@oracle.com> References: <64125402-3d3f-59b9-9253-9003b0b7676b@oracle.com> <080200b7-ce2e-76cb-763e-3e934f05aaaf@oracle.com> Message-ID: <69ecf86c-9ea1-d777-5ce9-59c7cc757d2c@oracle.com> Thanks for review Tony. Comments inline.. On 27/07/18 21:02, Anthony Scarpino wrote: > If we are going to add more, here are two more ton consider: > > - It looks like there is another Arrays.copyOf() on doFinal() line 851 Good point. > - doFinal() > at line 897 there might be something that should be done with > 'buffer'.? In particular as a result of line 963's arraycopy(). Yes - I've identified two areas where we can be proactive about nulling out 'buffer' contents. That's around the same time where we reset 'buffered' to 0. See lines 777 and 967 http://cr.openjdk.java.net/~coffeys/webrev.8207775.v3/webrev/ regards, Sean. > > Tony > > > On 07/27/2018 08:29 AM, Se?n Coffey wrote: >> Thanks Tony. If it's alright with you, I'd like to make one more edit >> for this change. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8207775.v2/webrev/ >> >> There's a condition where we can null out an array early if we're >> returning a copy. See lines 671-683 >> >> Regards, >> Sean. >> >> On 26/07/18 17:42, Anthony Scarpino wrote: >>> On 07/26/2018 07:36 AM, Se?n Coffey wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8207775 >>>> >>>> Simple enough fix to null out some internal buffers once they're no >>>> longer required. >>>> >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8207775/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>> >>> that looks fine.. >>> >>> Tony >> > From simone.bordet at gmail.com Tue Jul 31 09:39:51 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 31 Jul 2018 11:39:51 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> Message-ID: Hi, On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote: > Would you mind look at the code I posted in the following thread: > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html JDK 11+21: 1. client.closeOutbound() then goes into NEED_WRAP. 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING (?) 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. 4. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 5. Client unwraps 0 bytes (?) Current jdk11 tip with your patch: 1. client.closeOutbound() then goes into NEED_WRAP. 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. 4. Server wraps 0 bytes and stays in NEED_WRAP (?) I don't think this is right. While I previously complained about step 2 going into NOT_HANDSHAKING, if you now support full half close, then I think this may be reasonable, as the server may still send data and only later issue a close_notify. However, NEED_UNWRAP like it is now is also reasonable. At step 3, after the server unwraps the close_notify, the server should either stay in NOT_HANDSHAKING *and* require a call to closeOutbound() (which will move the state to NEED_WRAP), or it should go into NEED_WRAP *and* produce the close_notify. As it is now, SSLEngine tells the application to wrap(), but it wraps 0 bytes, but tells again the application to wrap(), but still produces 0 bytes, so it's going to be a tight spin loop - not good. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Tue Jul 31 10:10:05 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 31 Jul 2018 12:10:05 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> Message-ID: Hi, On Tue, Jul 31, 2018 at 11:39 AM Simone Bordet wrote: > > Hi, > On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote: > > Would you mind look at the code I posted in the following thread: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html > > JDK 11+21: > 1. client.closeOutbound() then goes into NEED_WRAP. > 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING (?) > 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. > 4. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > 5. Client unwraps 0 bytes (?) > > Current jdk11 tip with your patch: > 1. client.closeOutbound() then goes into NEED_WRAP. > 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. > 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. > 4. Server wraps 0 bytes and stays in NEED_WRAP (?) > > I don't think this is right. > > While I previously complained about step 2 going into NOT_HANDSHAKING, > if you now support full half close, then I think this may be > reasonable, as the server may still send data and only later issue a > close_notify. > However, NEED_UNWRAP like it is now is also reasonable. > > At step 3, after the server unwraps the close_notify, the server > should either stay in NOT_HANDSHAKING *and* require a call to > closeOutbound() (which will move the state to NEED_WRAP), or it should > go into NEED_WRAP *and* produce the close_notify. > As it is now, SSLEngine tells the application to wrap(), but it wraps > 0 bytes, but tells again the application to wrap(), but still produces > 0 bytes, so it's going to be a tight spin loop - not good. For completeness, calling server.closeOutbound() at step 4. correctly moves SSLEngine into NEED_WRAP and a subsequent wrap() produces the 24 bytes of the close_notify and result CLOSED, then goes into NOT_HANDSHAKING. I think the current behavior (with your patch) needs to be fixed. Since you implemented half-close, my preference would be this: 1. client.closeOutbound() then goes into NEED_WRAP. 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 3. Server unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 4. server.closeOutbound() then goes into NEED_WRAP. 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 6. Client unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Tue Jul 31 13:43:33 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 31 Jul 2018 06:43:33 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> Message-ID: <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> Hi Simone, Thanks for the quick feedback. Read more in-lines, please. On 7/31/2018 3:10 AM, Simone Bordet wrote: > Hi, > > On Tue, Jul 31, 2018 at 11:39 AM Simone Bordet wrote: >> >> Hi, >> On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote: >>> Would you mind look at the code I posted in the following thread: >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >> >> JDK 11+21: >> 1. client.closeOutbound() then goes into NEED_WRAP. >> 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING (?) >> 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. >> 4. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. >> 5. Client unwraps 0 bytes (?) >> >> Current jdk11 tip with your patch: >> 1. client.closeOutbound() then goes into NEED_WRAP. >> 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. >> 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. >> 4. Server wraps 0 bytes and stays in NEED_WRAP (?) >> >> I don't think this is right. >> >> While I previously complained about step 2 going into NOT_HANDSHAKING, >> if you now support full half close, then I think this may be >> reasonable, as the server may still send data and only later issue a >> close_notify. >> However, NEED_UNWRAP like it is now is also reasonable. >> >> At step 3, after the server unwraps the close_notify, the server >> should either stay in NOT_HANDSHAKING *and* require a call to >> closeOutbound() (which will move the state to NEED_WRAP), or it should >> go into NEED_WRAP *and* produce the close_notify. >> As it is now, SSLEngine tells the application to wrap(), but it wraps >> 0 bytes, but tells again the application to wrap(), but still produces >> 0 bytes, so it's going to be a tight spin loop - not good. > > For completeness, calling server.closeOutbound() at step 4. correctly > moves SSLEngine into NEED_WRAP and a subsequent wrap() produces the 24 > bytes of the close_notify and result CLOSED, then goes into > NOT_HANDSHAKING. > > I think the current behavior (with your patch) needs to be fixed. > Since you implemented half-close, my preference would be this: > > 1. client.closeOutbound() then goes into NEED_WRAP. > 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. It might be a problem for application to make a right decision if using CLOSED status and NOT_HANDSHAKING handshake status together. As the write side is close, the client now only be able to receiving data from peer. I think NEED_UNWRAP may be more appropriate for application development. However, the CLOSED status may be confusing as the client may still want to read something later. I may prefer to use OK/NEED_UNWRAP. What do you think? > 3. Server unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. Same reason as above, I may prefer to use OK/NEED_WRAP. > 4. server.closeOutbound() then goes into NEED_WRAP. > 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > 6. Client unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > Agreed. If no objections, I will make the update: 1. client.closeOutbound() then goes into NEED_WRAP. 2. Client wraps 24 bytes, result is OK, then goes into NEED_UNWRAP. 3. Server unwraps 24 bytes, result is OK, then goes into NEED_WRAP. 4. server.closeOutbound() then goes into NEED_WRAP. 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 6. Client unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. Thanks, Xuelei From xuelei.fan at oracle.com Tue Jul 31 14:13:33 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 31 Jul 2018 07:13:33 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> Message-ID: <58f66f03-96ac-5b95-d9c5-44acf2b0e6f5@oracle.com> The Status.CLOSED specification is defined as "The operation just closed this side of the SSLEngine, or the operation could not be completed because it was already closed.". My reading of the spec, the CLOSED status means half-close. If wrap() status is CLOSED, it means write side close; and unwrap() CLOSED is for read side close. I may prefer to: 1. client.closeOutbound() then goes into NEED_WRAP. 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. 4. server.closeOutbound() then goes into NEED_WRAP. 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 6. Client unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. Xuelei On 7/31/2018 6:43 AM, Xuelei Fan wrote: > Hi Simone, > > Thanks for the quick feedback.? Read more in-lines, please. > > On 7/31/2018 3:10 AM, Simone Bordet wrote: >> Hi, >> >> On Tue, Jul 31, 2018 at 11:39 AM Simone Bordet >> wrote: >>> >>> Hi, >>> On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan >>> wrote: >>>> Would you mind look at the code I posted in the following thread: >>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html >>>> >>> >>> JDK 11+21: >>> 1. client.closeOutbound() then goes into NEED_WRAP. >>> 2. Client wraps 24 bytes, result is CLOSED, then goes into >>> NOT_HANDSHAKING (?) >>> 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. >>> 4. Server wraps 24 bytes, result is CLOSED, then goes into >>> NOT_HANDSHAKING. >>> 5. Client unwraps 0 bytes (?) >>> >>> Current jdk11 tip with your patch: >>> 1. client.closeOutbound() then goes into NEED_WRAP. >>> 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. >>> 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. >>> 4. Server wraps 0 bytes and stays in NEED_WRAP (?) >>> >>> I don't think this is right. >>> >>> While I previously complained about step 2 going into NOT_HANDSHAKING, >>> if you now support full half close, then I think this may be >>> reasonable, as the server may still send data and only later issue a >>> close_notify. >>> However, NEED_UNWRAP like it is now is also reasonable. >>> >>> At step 3, after the server unwraps the close_notify, the server >>> should either stay in NOT_HANDSHAKING *and* require a call to >>> closeOutbound() (which will move the state to NEED_WRAP), or it should >>> go into NEED_WRAP *and* produce the close_notify. >>> As it is now, SSLEngine tells the application to wrap(), but it wraps >>> 0 bytes, but tells again the application to wrap(), but still produces >>> 0 bytes, so it's going to be a tight spin loop - not good. >> >> For completeness, calling server.closeOutbound() at step 4. correctly >> moves SSLEngine into NEED_WRAP and a subsequent wrap() produces the 24 >> bytes of the close_notify and result CLOSED, then goes into >> NOT_HANDSHAKING. >> >> I think the current behavior (with your patch) needs to be fixed. >> Since you implemented half-close, my preference would be this: >> >> 1. client.closeOutbound() then goes into NEED_WRAP. >> 2. Client wraps 24 bytes, result is CLOSED, then goes into >> NOT_HANDSHAKING. > It might be a problem for application to make a right decision if using > CLOSED status and NOT_HANDSHAKING handshake status together. > > As the write side is close, the client now only be able to receiving > data from peer.? I think NEED_UNWRAP may be more appropriate for > application development. > > However, the CLOSED status may be confusing as the client may still want > to read something later. > > I may prefer to use OK/NEED_UNWRAP.? What do you think? > >> 3. Server unwraps 24 bytes, result is CLOSED, then goes into >> NOT_HANDSHAKING. > Same reason as above, I may prefer to use OK/NEED_WRAP. > >> 4. server.closeOutbound() then goes into NEED_WRAP. >> 5. Server wraps 24 bytes, result is CLOSED, then goes into >> NOT_HANDSHAKING. >> 6. Client unwraps 24 bytes, result is CLOSED, then goes into >> NOT_HANDSHAKING. >> > Agreed. > > If no objections, I will make the update: > > 1. client.closeOutbound() then goes into NEED_WRAP. > 2. Client wraps 24 bytes, result is OK, then goes into NEED_UNWRAP. > 3. Server unwraps 24 bytes, result is OK, then goes into NEED_WRAP. > 4. server.closeOutbound() then goes into NEED_WRAP. > 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > 6. Client unwraps 24 bytes, result is CLOSED, then goes into > NOT_HANDSHAKING. > > Thanks, > Xuelei From simone.bordet at gmail.com Tue Jul 31 14:20:10 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 31 Jul 2018 16:20:10 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> Message-ID: Hi, On Tue, Jul 31, 2018 at 3:43 PM Xuelei Fan wrote: > > 1. client.closeOutbound() then goes into NEED_WRAP. > > 2. Client wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > It might be a problem for application to make a right decision if using > CLOSED status and NOT_HANDSHAKING handshake status together. > > As the write side is close, the client now only be able to receiving > data from peer. I think NEED_UNWRAP may be more appropriate for > application development. I think the key point here is that SSLEngine tells the application what needs to be done. Because you implemented half-close, NEED_UNWRAP is not _strictly_ needed here. By staying in NOT_HANDSHAKING the normal flow will happen: data to read from the server, pass to unwrap(), it may be data or close_notify. Let's imagine it is data; after unwrapping data, do you stay in NEED_UNWRAP until the close_notify arrives? I'm fine with either NOT_HANSHAKING or NEED_UNWRAP, but I prefer NOT_HANDSHAKING. > However, the CLOSED status may be confusing as the client may still want > to read something later. > > I may prefer to use OK/NEED_UNWRAP. What do you think? I prefer CLOSED/NOT_HANDSHAKING, but OK/NEED_UNWRAP works too. > > 3. Server unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > Same reason as above, I may prefer to use OK/NEED_WRAP. Here I strongly disagree. It is fundamental for the application to know that it received the close_notify from the client, because the application needs to call closeOutbound(), eventually. The CLOSED result is the only thing that tells the application to call closeOutbound(). I think this is also good for backwards compatibility: with TLS 1.2 I bet most application were relying on the CLOSED state. I prefer CLOSED/NOT_HANDSHAKING; CLOSED/NEED_WRAP is ok too. > > 4. server.closeOutbound() then goes into NEED_WRAP. > > 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > > 6. Client unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > > > Agreed. > > If no objections, I will make the update: > > 1. client.closeOutbound() then goes into NEED_WRAP. > 2. Client wraps 24 bytes, result is OK, then goes into NEED_UNWRAP. > 3. Server unwraps 24 bytes, result is OK, then goes into NEED_WRAP. Nope: CLOSED, then NEED_WRAP, see above. > 4. server.closeOutbound() then goes into NEED_WRAP. > 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > 6. Client unwraps 24 bytes, result is CLOSED, then goes into > NOT_HANDSHAKING. Let's make another case with data, and what I prefer: 1. client.closeOutbound() then goes into NEED_WRAP. 2. Client wraps 24 bytes, result is OK, then goes into NOT_HANDSHAKING. 3. Server unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 4. Server wraps data bytes, result is OK, stays in NOT_HANDSHAKING. 5. Client unwraps data bytes result is OK, stays in NOT_HANDSHAKING. 6. server.closeOutbound() then goes into NEED_WRAP. 7. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 8. Client unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. I'm fine for 2 and 5 to be NEED_UNWRAP; I'm fine for 3 and 4 to be NEED_WRAP. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Tue Jul 31 14:23:30 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 31 Jul 2018 16:23:30 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: <58f66f03-96ac-5b95-d9c5-44acf2b0e6f5@oracle.com> References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> <58f66f03-96ac-5b95-d9c5-44acf2b0e6f5@oracle.com> Message-ID: Hi, On Tue, Jul 31, 2018 at 4:13 PM Xuelei Fan wrote: > > The Status.CLOSED specification is defined as "The operation just closed > this side of the SSLEngine, or the operation could not be completed > because it was already closed.". My reading of the spec, the CLOSED > status means half-close. If wrap() status is CLOSED, it means write > side close; and unwrap() CLOSED is for read side close. > > I may prefer to: > 1. client.closeOutbound() then goes into NEED_WRAP. > 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. > 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. > 4. server.closeOutbound() then goes into NEED_WRAP. > 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. > 6. Client unwraps 24 bytes, result is CLOSED, then goes into > NOT_HANDSHAKING. Yes, we agreed that at step 2 and especially step 3 result must be CLOSED. Please consider the case where data is sent before the close_notify reply, and what would be good for you. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Tue Jul 31 14:33:05 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 31 Jul 2018 07:33:05 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> <58f66f03-96ac-5b95-d9c5-44acf2b0e6f5@oracle.com> Message-ID: Hi, Looks like we are on the same page now. For the data transportation (wrap/unwrap), I agree we'd better use OK so that applications can make the right decision. Thanks, Xuelei On 7/31/2018 7:23 AM, Simone Bordet wrote: > Hi, > On Tue, Jul 31, 2018 at 4:13 PM Xuelei Fan wrote: >> >> The Status.CLOSED specification is defined as "The operation just closed >> this side of the SSLEngine, or the operation could not be completed >> because it was already closed.". My reading of the spec, the CLOSED >> status means half-close. If wrap() status is CLOSED, it means write >> side close; and unwrap() CLOSED is for read side close. >> >> I may prefer to: >> 1. client.closeOutbound() then goes into NEED_WRAP. >> 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. >> 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. >> 4. server.closeOutbound() then goes into NEED_WRAP. >> 5. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. >> 6. Client unwraps 24 bytes, result is CLOSED, then goes into >> NOT_HANDSHAKING. > > Yes, we agreed that at step 2 and especially step 3 result must be CLOSED. > > Please consider the case where data is sent before the close_notify > reply, and what would be good for you. > > Thanks! > From xuelei.fan at oracle.com Tue Jul 31 15:10:10 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 31 Jul 2018 08:10:10 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> Message-ID: <9b041cf3-3caa-3f3c-ebec-70c012743b7d@oracle.com> Hi, On 7/31/2018 6:43 AM, Xuelei Fan wrote: > Current jdk11 tip with your patch: > 1. client.closeOutbound() then goes into NEED_WRAP. > 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. > 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. > 4. Server wraps 0 bytes and stays in NEED_WRAP (?) In my testing (OpenJDK, test/jdk/javax/net/ssl/TLSv1/TLSEnginesClosureTest.java), for #4, the server could wrap the close_notify alert message for TLS 1.2 and prior versions (CLOSED/NOT_HANDSHAKING); and wrap data for TLS 1.3 (OK/NOT_HANDSHAKING, half-close). Are you using TLS 1.3 with no data in your test case in #4? Because of the half-close policy, it may be the expected behavior if no application data can be delivered. Thanks, Xuelei For TLS 1.2: ------------------------ Trying to close engines from Client to Server Client wrapped 31 bytes. Client handshake status is NEED_UNWRAP Result is CLOSED Server unwrapping 31 bytes... Server handshake status is NEED_WRAP Result is CLOSED Server wrapped 31 bytes. Server handshake status is NOT_HANDSHAKING Result is CLOSED Client unwrapping 31 bytes... Client handshake status is NOT_HANDSHAKING Result is CLOSED Client wrapped 0 bytes. Client handshake status is NOT_HANDSHAKING Result is CLOSED Server unwrapping 0 bytes... Server handshake status is NOT_HANDSHAKING Result is CLOSED Successful closing from Client to Server ------------------------ For TLS 1.3 ------------------------ Trying to close engines from Client to Server Client wrapped 24 bytes. Client handshake status is NEED_UNWRAP Result is CLOSED Server unwrapping 24 bytes... Server handshake status is NEED_WRAP Result is CLOSED Server wrapped 16406 bytes. Server handshake status is NEED_WRAP Result is OK ------------------------ From sean.mullan at oracle.com Tue Jul 31 15:58:10 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 31 Jul 2018 11:58:10 -0400 Subject: CFV: New Security Group Member: Adam Petcher Message-ID: I hereby nominate Adam Petcher to Membership in the Security Group. Adam is a member of the Security Libraries Team at Oracle and has a strong background in cryptography. He has been working on security for the JDK since December 2016. Adam is also the lead of 2 significant crypto related JEPs, one which will be delivered in JDK 11, and the other which is currently a Candidate: - JEP 324: Key Agreement with Curve25519 and Curve448 (http://openjdk.java.net/jeps/324) - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) (http://openjdk.java.net/jeps/339) Votes are due by 17:00 GMT Tuesday August 14, 2018. Only current Members of the Security Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Sean Mullan [1] http://openjdk.java.net/census#security [2] http://openjdk.java.net/groups/#member-vote From sean.mullan at oracle.com Tue Jul 31 16:00:21 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 31 Jul 2018 12:00:21 -0400 Subject: CFV: New Security Group Member: Adam Petcher In-Reply-To: References: Message-ID: <10aff3b2-7ad0-cf3c-b37f-88dfae6e4ab5@oracle.com> Vote: yes --Sean From jamil.j.nimeh at oracle.com Tue Jul 31 16:41:50 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 31 Jul 2018 09:41:50 -0700 Subject: CFV: New Security Group Member: Adam Petcher In-Reply-To: References: Message-ID: <708614f9-8b1c-12e7-c45d-7481ee5b7af5@oracle.com> Vote: yes On 07/31/2018 08:58 AM, Sean Mullan wrote: > I hereby nominate Adam Petcher to Membership in the Security Group. > > Adam is a member of the Security Libraries Team at Oracle and has a > strong background in cryptography. He has been working on security for > the JDK since December 2016. Adam is also the lead of 2 significant > crypto related JEPs, one which will be delivered in JDK 11, and the > other which is currently a Candidate: > > ?? - JEP 324: Key Agreement with Curve25519 and Curve448 > (http://openjdk.java.net/jeps/324) > ?? - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) > (http://openjdk.java.net/jeps/339) > > Votes are due by 17:00 GMT Tuesday August 14, 2018. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote From weijun.wang at oracle.com Tue Jul 31 16:43:00 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 1 Aug 2018 00:43:00 +0800 Subject: CFV: New Security Group Member: Adam Petcher In-Reply-To: References: Message-ID: <2D9422D9-703D-4AF1-A7C1-8E815C5AF7B3@oracle.com> Vote: yes --weijun > On Jul 31, 2018, at 11:58 PM, Sean Mullan wrote: > > I hereby nominate Adam Petcher to Membership in the Security Group. From xuelei.fan at oracle.com Tue Jul 31 17:09:08 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 31 Jul 2018 10:09:08 -0700 Subject: CFV: New Security Group Member: Adam Petcher In-Reply-To: References: Message-ID: <98297117-fb6b-c1dc-6a63-6b1177b164ab@oracle.com> Vote: Yes On 7/31/2018 8:58 AM, Sean Mullan wrote: > I hereby nominate Adam Petcher to Membership in the Security Group. > > Adam is a member of the Security Libraries Team at Oracle and has a > strong background in cryptography. He has been working on security for > the JDK since December 2016. Adam is also the lead of 2 significant > crypto related JEPs, one which will be delivered in JDK 11, and the > other which is currently a Candidate: > > ?? - JEP 324: Key Agreement with Curve25519 and Curve448 > (http://openjdk.java.net/jeps/324) > ?? - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) > (http://openjdk.java.net/jeps/339) > > Votes are due by 17:00 GMT Tuesday August 14, 2018. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote From anthony.scarpino at oracle.com Tue Jul 31 17:45:30 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 31 Jul 2018 10:45:30 -0700 Subject: CFV: New Security Group Member: Adam Petcher In-Reply-To: References: Message-ID: Vote: Yes On 07/31/2018 08:58 AM, Sean Mullan wrote: > I hereby nominate Adam Petcher to Membership in the Security Group. > > Adam is a member of the Security Libraries Team at Oracle and has a > strong background in cryptography. He has been working on security for > the JDK since December 2016. Adam is also the lead of 2 significant > crypto related JEPs, one which will be delivered in JDK 11, and the > other which is currently a Candidate: > > ?? - JEP 324: Key Agreement with Curve25519 and Curve448 > (http://openjdk.java.net/jeps/324) > ?? - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) > (http://openjdk.java.net/jeps/339) > > Votes are due by 17:00 GMT Tuesday August 14, 2018. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote From sean.coffey at oracle.com Tue Jul 31 19:11:38 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 31 Jul 2018 20:11:38 +0100 Subject: RFR: 8208583: Better management of internal KeyStore buffers Message-ID: Looking to improve management of internal buffers in KeyStore. The com.sun.crypto.provider.KeyProtector class uses the PBEKey class to protect some keys. Buffers can be freed up earlier if the caller takes responsibility for lifecycle of PBEKey object. (hence no reliance on Cleaner). Some other minor improvements made while visiting this area. Other improvements in sun.security.provider.KeyProtector where I believe the password buffer can be managed by the caller.? I only found 2 instances of where this class is used. https://bugs.openjdk.java.net/browse/JDK-8208583 http://cr.openjdk.java.net/~coffeys/webrev.8208583.v1/webrev/index.html regards, Sean. From simone.bordet at gmail.com Tue Jul 31 19:13:01 2018 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 31 Jul 2018 21:13:01 +0200 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: <9b041cf3-3caa-3f3c-ebec-70c012743b7d@oracle.com> References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> <9b041cf3-3caa-3f3c-ebec-70c012743b7d@oracle.com> Message-ID: Hi, On Tue, Jul 31, 2018 at 5:10 PM Xuelei Fan wrote: > > Hi, > > On 7/31/2018 6:43 AM, Xuelei Fan wrote: > > Current jdk11 tip with your patch: > > 1. client.closeOutbound() then goes into NEED_WRAP. > > 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. > > 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. > > 4. Server wraps 0 bytes and stays in NEED_WRAP (?) > > In my testing (OpenJDK, > test/jdk/javax/net/ssl/TLSv1/TLSEnginesClosureTest.java), for #4, the > server could wrap the close_notify alert message for TLS 1.2 and prior > versions (CLOSED/NOT_HANDSHAKING); and wrap data for TLS 1.3 > (OK/NOT_HANDSHAKING, half-close). > > Are you using TLS 1.3 with no data in your test case in #4? Because of > the half-close policy, it may be the expected behavior if no > application data can be delivered. The problem with 4 between TLS 1.2 and your latest patch is that before there was no need to call server.closeOutbound(): as the server received the close_notify from the client, it was moving to NEED_WRAP and if wrap() was called it would generate the close_notify reply. With your latest patch, you _have_ to call server.closeOutbound() otherwise 4 will always generate 0 bytes and spin loop. That is why I prefer 2 to go into CLOSED+NOT_HANDSHAKING. When it goes into CLOSE+NEED_UNWRAP, the application will follow the instructions of SSLEngine and attempt an unwrap() immediately, while instead it should stop wrapping/unwrapping and write the close_notify to the server. > For TLS 1.3 > ------------------------ > Trying to close engines from Client to Server > Client wrapped 24 bytes. > Client handshake status is NEED_UNWRAP Result is CLOSED > Server unwrapping 24 bytes... > Server handshake status is NEED_WRAP Result is CLOSED > Server wrapped 16406 bytes. > Server handshake status is NEED_WRAP Result is OK > ------------------------ The above tells me that the server did not generate yet the close_notify reply because it is still in NEED_WRAP. Just to repeat myself I would prefer this: > Client called closeOutbound() status is NEED_WRAP > Client wrapped 24 bytes. > Client handshake status is NOT_HANDSHAKING Result is CLOSED > Server unwrapping 24 bytes... > Server handshake status is NOT_HANDSHAKING Result is CLOSED > Server wrapped 16406 bytes. > Server handshake status is NOT_HANDSHAKING Result is OK > Server called closeOutbound() status is NEED_WRAP > Server wraps 24 bytes > Server handshake status is NOT_HANDSHAKING Result is CLOSED Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Tue Jul 31 19:56:27 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 31 Jul 2018 12:56:27 -0700 Subject: SSLEngine weird behavior in 11+21? In-Reply-To: References: <97baced5-03fa-5b5f-2559-841ec6d86ae4@oracle.com> <7998962c-9060-b1cd-8116-17da18981796@oracle.com> <4e3f8e9a-63f2-13b1-49a4-5fcb9a005f2f@oracle.com> <9b041cf3-3caa-3f3c-ebec-70c012743b7d@oracle.com> Message-ID: <3a986da4-20b8-c66c-aee3-603dfaedd6a4@oracle.com> On 7/31/2018 12:13 PM, Simone Bordet wrote: > Hi, > > On Tue, Jul 31, 2018 at 5:10 PM Xuelei Fan wrote: >> >> Hi, >> >> On 7/31/2018 6:43 AM, Xuelei Fan wrote: >>> Current jdk11 tip with your patch: >>> 1. client.closeOutbound() then goes into NEED_WRAP. >>> 2. Client wraps 24 bytes, result is CLOSED, then goes into NEED_UNWRAP. >>> 3. Server unwraps 24 bytes, result is CLOSED, then goes into NEED_WRAP. >>> 4. Server wraps 0 bytes and stays in NEED_WRAP (?) >> >> In my testing (OpenJDK, >> test/jdk/javax/net/ssl/TLSv1/TLSEnginesClosureTest.java), for #4, the >> server could wrap the close_notify alert message for TLS 1.2 and prior >> versions (CLOSED/NOT_HANDSHAKING); and wrap data for TLS 1.3 >> (OK/NOT_HANDSHAKING, half-close). >> >> Are you using TLS 1.3 with no data in your test case in #4? Because of >> the half-close policy, it may be the expected behavior if no >> application data can be delivered. > > The problem with 4 between TLS 1.2 and your latest patch is that > before there was no need to call server.closeOutbound(): as the server > received the close_notify from the client, it was moving to NEED_WRAP > and if wrap() was called it would generate the close_notify reply. > With your latest patch, you _have_ to call server.closeOutbound() > otherwise 4 will always generate 0 bytes and spin loop. > > That is why I prefer 2 to go into CLOSED+NOT_HANDSHAKING. > When it goes into CLOSE+NEED_UNWRAP, the application will follow the > instructions of SSLEngine and attempt an unwrap() immediately, while > instead it should stop wrapping/unwrapping and write the close_notify > to the server. > Hm, I see your point. Because of the half-close policy, I think the server could keep sending messages other than the close_notify alert. My concern of the CLOSED+NOT_HANDSHAKING is that it does not indicate the following operations. Applications may call unwrap(), and run into problems. It looks that it is tolerable to use wrap() with no application data (generate 0 bytes). >> For TLS 1.3 >> ------------------------ >> Trying to close engines from Client to Server >> Client wrapped 24 bytes. >> Client handshake status is NEED_UNWRAP Result is CLOSED >> Server unwrapping 24 bytes... >> Server handshake status is NEED_WRAP Result is CLOSED >> Server wrapped 16406 bytes. >> Server handshake status is NEED_WRAP Result is OK >> ------------------------ > > The above tells me that the server did not generate yet the > close_notify reply because it is still in NEED_WRAP. Yes, but it is the desired behavior to me. For the TLS 1.3 half close policy, it is not expected to generate close_notify reply unless the server close its outbound. So the server can keep sending the application data after the read close, as it write side is open. The TLS 1.3 spec says: "Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert. This does not have any effect on its read side of the connection." And the SSLEngine.closeOutbound() spec says: "Signals that no more outbound application data will be sent on this SSLEngine." I think it is fine to keep the write side open while the read side closed. In this update, for TLS 1.2 connection, the duplex-close behavior is reserved: as the server received the close_notify, it moving to NEED_WRAP; and the a close_notify will be delivered, and then duplex close the connection. However, for TLS 1.3 connection, if there is no call to server.closeOutbound(), the server write side keeps open even the read side has been closed. In this update, for TLS 1.3, I tried to support half-close for: 1. SSLEngine.closeIn/Outbound() 2. SSLSocket.shutdownIn/Output() and duplex-close for: 3. SSLSocket.close() Unfortunately, it does introduce a compatibility issue that an existing application may not close both inbound and outbound if the connection is desired to be duplex-closed. In order to mitigate the impact, a new System Property in introduced, "jdk.tls.acknowledgeCloseNotify". This compatibility issues could be mitigated by closing both inbound and outbound explicitly, or set the property to "true". If the property value is "true", a corresponding close_notify alert will be sent when receiving a close_notify alert, and therefore the connection will be duplex closed. Does it make sense to you? Xuelei > Just to repeat myself I would prefer this: > >> Client called closeOutbound() status is NEED_WRAP >> Client wrapped 24 bytes. >> Client handshake status is NOT_HANDSHAKING Result is CLOSED >> Server unwrapping 24 bytes... >> Server handshake status is NOT_HANDSHAKING Result is CLOSED >> Server wrapped 16406 bytes. >> Server handshake status is NOT_HANDSHAKING Result is OK >> Server called closeOutbound() status is NEED_WRAP >> Server wraps 24 bytes >> Server handshake status is NOT_HANDSHAKING Result is CLOSED > > Thanks! > From sean.mullan at oracle.com Tue Jul 31 19:56:55 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 31 Jul 2018 15:56:55 -0400 Subject: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized In-Reply-To: <68B87EA5-6F86-4970-AB80-556D4783CF28@oracle.com> References: <93676c63-04c2-c614-3b35-014107c74531@oracle.com> <285da72d-905b-b552-dfdf-9a2962ef15e1@oracle.com> <9ef061f5-620a-4aee-ede1-a5b5fd74132d@oracle.com> <81FCEC9C-97E3-4B05-9D89-6FB3BB666074@oracle.com> <0613557d-ae92-25eb-2020-a2300d5a971a@oracle.com> <511F1C2C-B04F-4E7C-B483-CA3664AFA86B@oracle.com> <3695CD90-B1C6-441C-B1E7-215CC4C914D9@oracle.com> <31c554ab-916e-d23d-860e-551d31f01f16@oracle.com> <5e715573-75f3-b900-b3db-798767e90be3@oracle.com> <19470b78-d52e-b476-d879-6959760c4f6a@oracle.com> <8601c0bb-0f73-76d6-8ad0-5f8dd3e788e0@oracle.com> <68B87EA5-6F86-4970-AB80-556D4783CF28@oracle.com> Message-ID: On 7/24/18 9:38 PM, Weijun Wang wrote: > Something related. > > Cipher has a similar init(..,params) and getParameters() structure and the spec is also similar. > > *

The returned parameters may be the same that were used to initialize > * this cipher, or may contain a combination of default and random > * parameter values used by the underlying cipher implementation if this > * cipher requires algorithm parameters but was not initialized with any. > > However, one can supply an incomplete parameters object in init() and getParameters() will fill in default/random values to make it complete. > > For example, in PBE-based Cipher, one can only include salt and iteration count in the init params, and init() will add in a random IV, and the IV can be retrieved with getParameters(). > > Is this something we need to clarify? Yes, we should update the Cipher API to be consistent with Signature. I think this can wait until JDK 12 though. Valerie, can you file a follow-on issue? Thanks, Sean From bradford.wetmore at oracle.com Tue Jul 31 21:03:29 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 31 Jul 2018 14:03:29 -0700 Subject: CFV: New Security Group Member: Adam Petcher In-Reply-To: References: Message-ID: <77d24c7e-a90b-85ad-6a51-bcd836f441ab@oracle.com> Vote: Yes. Brad On 7/31/2018 8:58 AM, Sean Mullan wrote: > I hereby nominate Adam Petcher to Membership in the Security Group. > > Adam is a member of the Security Libraries Team at Oracle and has a > strong background in cryptography. He has been working on security for > the JDK since December 2016. Adam is also the lead of 2 significant > crypto related JEPs, one which will be delivered in JDK 11, and the > other which is currently a Candidate: > > ?? - JEP 324: Key Agreement with Curve25519 and Curve448 > (http://openjdk.java.net/jeps/324) > ?? - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) > (http://openjdk.java.net/jeps/339) > > Votes are due by 17:00 GMT Tuesday August 14, 2018. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination.? Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote From valerie.peng at oracle.com Tue Jul 31 23:26:04 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 31 Jul 2018 16:26:04 -0700 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> Message-ID: <7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> Hi Martin, Here are the review comments for the remaining files: - Always check non-null result for JNIEnv FindClass(...) calls, e.g. line 530 and 802 - Sometimes the check is there but is after the return value has been used. These checks should be moved up, i.e. right after the FindClass(..) calls, e.g. line 555, 834. - line 1262, should be CK_TLS12_MASTER_KEY_DERIVE_PARAMS instead of CK_TLS12_MASTER_KEY_DERIVE_PARAMS_PTR Thanks, Valerie On 7/26/2018 9:12 AM, Martin Balao wrote: > Hi Valerie, > > Thanks for your feedback! > > CKM_TLS12_MAC looks like it's not in use. Authentication codes are > calculated through CKM_TLS12_KEY_AND_MAC_DERIVE mechanism. Do you know > of a library supporting CKM_TLS12_MAC but not > CKM_TLS12_KEY_AND_MAC_DERIVE? I've been testing this with NSS software > token which does not support CKM_TLS12_MAC. > > module-info.java changes were from when we used SSL/TLS constants, but > then I replaced these constants with hardcoded numbers -after > discussing with Xuelei-. I forgot to revert changes on this file. Thanks. > > Config.java changes were from a wrong version I uploaded. This has > been already fixed. > > SunPKCS11.java: I agree with you that registration must be done > separately. SunTls12MasterSecret and SunTls12KeyMaterial are now > registered separately. I've added CKM_TLS12_MASTER_KEY_DERIVE_DH > mechanism to SunTls12MasterSecret algorithm. It's still assumed that > if CKM_TLS12_MASTER_KEY_DERIVE is supported, then > CKM_TLS12_MASTER_KEY_DERIVE_DH it's and vice-versa -same as with > previous key derivation mechanisms-. Not a big deal though I think: > it's unlikely that a library implements only one of these. Using > protocol version to decide which mechanism to use should be valid in > this case because if an instance of P11TlsMasterSecretGenerator is > used and algorithm is SunTls12MasterSecret, then protocol must be TLS > 1.2 and we can assume that there is support of these mechanisms in the > underlying library. > L527: I've realized that a better place for this map is > Functions.java. I've moved it there. > > P11TlsPrfGenerator.java: This code is for TLS 1.2 only. That's because > CKM_TLS_MAC mechanism is registered for SunTls12Prf algorithm. > Previous TLS versions use CKM_TLS_PRF and CKM_NSS_TLS_PRF_GENERAL. > > P11TlsRsaPremasterSecretGenerator.java: Yes, we can remove it and call > all keys "TlsRsaPremasterSecret", disregarding the mechanism used to > generate it (CKM_SSL3_PRE_MASTER_KEY_GEN or > CKM_TLS_PRE_MASTER_KEY_GEN). At the end of the day, this is just an > array of 48 bytes. I've removed the field too. > > Functions.java: New entries (CKM_TLS12_MASTER_KEY_DERIVE, > CKM_TLS12_MASTER_KEY_DERIVE_DH and CKM_TLS_MAC) moved after line 721. > CKM_TLS12_KEY_AND_MAC_DERIVE has been added for completeness. > > CK_ATTRIBUTE.java: SENSITIVE_TRUE removed. > > Removed a dependency in TestTLS12.java to HexDumper (internal). > > Webrev 06 with all these changes here: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06/ > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06.zip > > > Regression testing on jdk/sun/security/pkcs11 passes with samae pass rate. > > Kind regards, > Martin.- > > On Tue, Jul 24, 2018 at 11:00 PM, Valerie Peng > > wrote: > > Hi Martin, > > Sorry for the delay, I am able to resume on reviewing this now. > > Here are some initial comments. > > What about CKM_TLS12_MAC? I see that it's defined under TLS 1.2 > mechanisms, but not much other details for it. > > > - Is this change still necessary? I didn't notice any new import > statement with sun.security.ssl package in the rest of changes. > > > - Why removing the SENSITIVE_FALSE attribute on line 829 and 854? > > > - As my comments for the SunPKCS11.java (see below), I think we > should not assume the support for CKM_TLS12_KEY_AND_MAC_DERIVE. > The existing impl and how it's registered in SunPKCS11 class is > already somewhat problematic when CKM_TLS_KEY_AND_MAC_DERIVE is > not supported. We should avoid assuming > CKM_TLS12_KEY_AND_MAC_DERIVE is supported which may create even > more problems. Overriding this.mechanism based on the TLS version > specified in the parameters from the engineInit(...) call will > lead to failure when the mechanism is not supported by underlying > PKCS11 library > > > - Please see above comments for P11TlsKeyMaterialGenerator.java > > > - Retrieve label outside of the new code block for TLS 1.2, i.e. > line 133- 167, as it's used by all mechanisms. > > > - Line 131, Is it really necessary to use > SunTls12RsaPremasterSecret? SunJCE provider uses > SunTlsRsaPremasterSecret for all cases. If different algorithm is > not needed, then no need to save tlsVersion as a field > > > - Hmm, for TLS 12 specific mechanisms, some PKCS11 libraries may > not support them. Instead of registering > SunTls12MasterSecret/SunTls12KeyMaterial as aliases, they should > be registered separately so that if the native TLS 12 mechanisms > were not supported, the new entry will be skipped. The > corresponding implementation classes such as > P11TlsMasterSecretGenerator and P11TlsKeyMaterialGenerator will > have to check the specified parameter spec in their engineInit(..) > calls to make sure things line up, e.g. error out if the TLS > version in the spec does not match the native mechanism. > - Lines 528 - 532, the mapping is stored without checking for > support. May become an issue when the underlying PKCS11 library > does not support all of these hash mechanisms. Probably not a big > deal as these are fairly common hash algorithms, but I think it'd > be good to add a comment on line 527 with something like "// > assuming all hash mechanisms below are supported". > > > - Miss the mapping for CKM_TLS12_KEY_AND_MAC_DERIVE? Move these > new entries to be after the existing SSL3/TLS entries (from line > 711-721) > > I still have a few files left and will send you comments on them > later. > Thanks, > Valerie > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Jul 31 23:48:59 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 31 Jul 2018 16:48:59 -0700 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> <7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> Message-ID: I sent this email a bit prematurely. I still need to review TestTLS12.java. All else is done. Valerie On 7/31/2018 4:26 PM, Valerie Peng wrote: > > Hi Martin, > > Here are the review comments for the remaining files: > > > > - Always check non-null result for JNIEnv FindClass(...) calls, e.g. > line 530 and 802 > > - Sometimes the check is there but is after the return value has been > used. These checks should be moved up, i.e. right after the > FindClass(..) calls, e.g. line 555, 834. > > - line 1262, should be CK_TLS12_MASTER_KEY_DERIVE_PARAMS instead of > CK_TLS12_MASTER_KEY_DERIVE_PARAMS_PTR > > > Thanks, > Valerie > > > On 7/26/2018 9:12 AM, Martin Balao wrote: >> Hi Valerie, >> >> Thanks for your feedback! >> >> CKM_TLS12_MAC looks like it's not in use. Authentication codes are >> calculated through CKM_TLS12_KEY_AND_MAC_DERIVE mechanism. Do you >> know of a library supporting CKM_TLS12_MAC but not >> CKM_TLS12_KEY_AND_MAC_DERIVE? I've been testing this with NSS >> software token which does not support CKM_TLS12_MAC. >> >> module-info.java changes were from when we used SSL/TLS constants, >> but then I replaced these constants with hardcoded numbers -after >> discussing with Xuelei-. I forgot to revert changes on this file. Thanks. >> >> Config.java changes were from a wrong version I uploaded. This has >> been already fixed. >> >> SunPKCS11.java: I agree with you that registration must be done >> separately. SunTls12MasterSecret and SunTls12KeyMaterial are now >> registered separately. I've added CKM_TLS12_MASTER_KEY_DERIVE_DH >> mechanism to SunTls12MasterSecret algorithm. It's still assumed that >> if CKM_TLS12_MASTER_KEY_DERIVE is supported, then >> CKM_TLS12_MASTER_KEY_DERIVE_DH it's and vice-versa -same as with >> previous key derivation mechanisms-. Not a big deal though I think: >> it's unlikely that a library implements only one of these. Using >> protocol version to decide which mechanism to use should be valid in >> this case because if an instance of P11TlsMasterSecretGenerator is >> used and algorithm is SunTls12MasterSecret, then protocol must be TLS >> 1.2 and we can assume that there is support of these mechanisms in >> the underlying library. >> L527: I've realized that a better place for this map is >> Functions.java. I've moved it there. >> >> P11TlsPrfGenerator.java: This code is for TLS 1.2 only. That's >> because CKM_TLS_MAC mechanism is registered for SunTls12Prf >> algorithm. Previous TLS versions use CKM_TLS_PRF and >> CKM_NSS_TLS_PRF_GENERAL. >> >> P11TlsRsaPremasterSecretGenerator.java: Yes, we can remove it and >> call all keys "TlsRsaPremasterSecret", disregarding the mechanism >> used to generate it (CKM_SSL3_PRE_MASTER_KEY_GEN or >> CKM_TLS_PRE_MASTER_KEY_GEN). At the end of the day, this is just an >> array of 48 bytes. I've removed the field too. >> >> Functions.java: New entries (CKM_TLS12_MASTER_KEY_DERIVE, >> CKM_TLS12_MASTER_KEY_DERIVE_DH and CKM_TLS_MAC) moved after line 721. >> CKM_TLS12_KEY_AND_MAC_DERIVE has been added for completeness. >> >> CK_ATTRIBUTE.java: SENSITIVE_TRUE removed. >> >> Removed a dependency in TestTLS12.java to HexDumper (internal). >> >> Webrev 06 with all these changes here: >> >> ?* >> http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06/ >> >> ?* >> http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.06.zip >> >> >> Regression testing on jdk/sun/security/pkcs11 passes with samae pass >> rate. >> >> Kind regards, >> Martin.- >> >> On Tue, Jul 24, 2018 at 11:00 PM, Valerie Peng >> > wrote: >> >> Hi Martin, >> >> Sorry for the delay, I am able to resume on reviewing this now. >> >> Here are some initial comments. >> >> What about CKM_TLS12_MAC? I see that it's defined under TLS 1.2 >> mechanisms, but not much other details for it. >> >> >> - Is this change still necessary? I didn't notice any new import >> statement with sun.security.ssl package in the rest of changes. >> >> >> - Why removing the SENSITIVE_FALSE attribute on line 829 and 854? >> >> >> - As my comments for the SunPKCS11.java (see below), I think we >> should not assume the support for CKM_TLS12_KEY_AND_MAC_DERIVE. >> The existing impl and how it's registered in SunPKCS11 class is >> already somewhat problematic when CKM_TLS_KEY_AND_MAC_DERIVE is >> not supported. We should avoid assuming >> CKM_TLS12_KEY_AND_MAC_DERIVE is supported which may create even >> more problems. Overriding this.mechanism based on the TLS version >> specified in the parameters from the engineInit(...) call will >> lead to failure when the mechanism is not supported by underlying >> PKCS11 library >> >> >> - Please see above comments for P11TlsKeyMaterialGenerator.java >> >> >> - Retrieve label outside of the new code block for TLS 1.2, i.e. >> line 133- 167, as it's used by all mechanisms. >> >> >> - Line 131, Is it really necessary to use >> SunTls12RsaPremasterSecret? SunJCE provider uses >> SunTlsRsaPremasterSecret for all cases. If different algorithm is >> not needed, then no need to save tlsVersion as a field >> >> >> - Hmm, for TLS 12 specific mechanisms, some PKCS11 libraries may >> not support them. Instead of registering >> SunTls12MasterSecret/SunTls12KeyMaterial as aliases, they should >> be registered separately so that if the native TLS 12 mechanisms >> were not supported, the new entry will be skipped. The >> corresponding implementation classes such as >> P11TlsMasterSecretGenerator and P11TlsKeyMaterialGenerator will >> have to check the specified parameter spec in their >> engineInit(..) calls to make sure things line up, e.g. error out >> if the TLS version in the spec does not match the native mechanism. >> - Lines 528 - 532, the mapping is stored without checking for >> support. May become an issue when the underlying PKCS11 library >> does not support all of these hash mechanisms. Probably not a big >> deal as these are fairly common hash algorithms, but I think it'd >> be good to add a comment on line 527 with something like "// >> assuming all hash mechanisms below are supported". >> >> >> - Miss the mapping for CKM_TLS12_KEY_AND_MAC_DERIVE? Move these >> new entries to be after the existing SSL3/TLS entries (from line >> 711-721) >> >> I still have a few files left and will send you comments on them >> later. >> Thanks, >> Valerie >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: