Re: Code Review Request, JDK-8207029 Unable to use custom SSLEngine with default TrustManagerFactory after updating to JDK 11 b21

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 prov

Code Review Request, JDK-8207029 Unable to use custom SSLEngine with default TrustManagerFactory after updating to JDK 11 b21

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

Re: SSLEngine weird behavior in 11+21?

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

Re: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)"

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 jd

SSLEngine weird behavior in 11+21?

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 go

Re: RFR 8206915: XDH TCK issues

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

Re: RFR 8206915: XDH TCK issues

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 clonin

Re: RFR[12] JDK-8179098 "Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73)"

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.o

Re: RFR 8206915: XDH TCK issues

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 t

Re: [11] RFR 8206189: sun/security/pkcs12/EmptyPassword.java fails with Sequence tag error

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 c

Re: RFR 8206915: XDH TCK issues

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

RE: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk

Hi Rajan, thanks for filing JDK-8207059. Best regards, Matthias From: Rajan Halade [mailto:[email protected]] Sent: Mittwoch, 11. Juli 2018 17:42 To: Baesken, Matthias ; [email protected] Subject: Re: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA

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 be

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

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:

Re: RFR 8206915: XDH TCK issues

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 i

security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk

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(Validate

Re: RFR 8206915: XDH TCK issues

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

Re: RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized

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

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

ountedOpenSslContext.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: > <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20180711/c207ae06/attachment.html> > > End of security-dev Digest, Vol 133, Issue 12 > *

Re: JDK 11+21 SSLSocket.close() deadlock?

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()