sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3

Hi all, In netty we support using OpenSSL for native SSL which recently added TLSv1.3 support as part of OpenSSL 1.1.1. In an ideal world we would be able to use this even with Java8 which is almost true except the fact that sun.security.ssl.ProtocolVersion.valueOf(…) will throw an IllegalArgu

Re: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well

Should I open an issue somewhere to keep track of it or will you take care of it ? Bye Norman > On 11. Sep 2018, at 17:01, Norman Maurer wrote: > > This sounds great. > > I have no idea how many people still use X509TrustManager, sorry. > > It may be a good idea to

Re: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well

Done.. ID: 9057278 Thanks Norman > On 17. Sep 2018, at 18:51, Xuelei Fan wrote: > > Hi Norman, > > Please file an issue for the tracking. > > Thanks, > Xuelei > > On 9/17/2018 5:57 AM, Norman Maurer wrote: >> Should I open an issue somewhere to ke

Re: sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3

tion when > there is a chance. > > Thanks, > Xuelei > > On 9/17/2018 5:28 AM, Norman Maurer wrote: >> Hi all, >> In netty we support using OpenSSL for native SSL which recently added >> TLSv1.3 support as part of OpenSSL 1.1.1. In an ideal world we would be able >&g

Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

fter consuming the > CertificateRequest message. Thanks to Norman Maurer for bringing this to our > attention. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210846 > > --Jamil >

Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

lly. > > Brad > > > On 9/19/2018 1:59 PM, Norman Maurer wrote: >> I will test and report back later today . Thanks for the quick turnaround >>> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh : >>> >>> Hello all, >>> >>> This fix han

Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

appropriate for this and a couple of other needed fixes. > > Hope this helps. > > Brad > > > > >> On 9/19/2018 9:34 AM, Xuelei Fan wrote: >> Hi Norman, >> It is just a initial version set. >> Thanks, >> Xuelei >>> On 9/19/2018 8:49 AM, N

NPE during SSL handshake caused by HostnameChecker

Hi all, I think I found another bug in the the SSL implementation (well really in the TrustManager related part) which leads to a NPE. I was able to reproduce this on Java8 and Java11 (ea28) but I am sure it also exists on 9 and 10. While trying to write some test code for netty I did somethin

Re: NPE during SSL handshake caused by HostnameChecker

g to me. Would you please file a new bug? > > Thanks, > Xuelei > > On 9/22/2018 3:40 PM, Norman Maurer wrote: >> Hi all, >> I think I found another bug in the the SSL implementation (well really in >> the TrustManager related part) which leads to a NPE. I wa

Re: sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3

So I did some more testing and all in all it seems to work. I will do some more investigating still and then log the request if I can not see any negative side-effects. Bye Norman > On 18. Sep 2018, at 18:08, Norman Maurer wrote: > > I did some testing and it seems to “just work”.

Re: RFR[s] 8211339: NPE during SSL handshake caused by HostnameChecker

LGTM as well… thanks a lot! > On 5. Nov 2018, at 20:22, Xuelei Fan wrote: > > It looks fine to me. > > Thanks, > Xuelei > > On 11/5/2018 10:59 AM, Anthony Scarpino wrote: >> Hi, >> I'd like to get a code review of this simple change. It's a simple check to >> make sure the hostname variable

Re: java.lang.NoSuchFieldError: state

I think this may be caused by using the wrong jetty alpn version. Be sure you use the correct one. For example 2.0.9: https://github.com/jetty-project/jetty-alpn-agent/releases Bye Norman > On 6. Nov 2018, at 07:46, Martin Choma wr

Possible bug in SSLEngine / SSLSession implementation

Hi all, While working on some unit tests in netty I noticed that there may be a bug in the JDK implementation of SSLEngine / SSLSession. If its not a but it is at least surprising I would say. So it seems like before the handshake all values that are set on the SSLSession via putValue are sha

Re: Possible bug in SSLEngine / SSLSession implementation

ing soon is better TLS session object > management and new session ticket management so we can avoid these value > propagation issues in the future. > > --Jamil > > On 12/11/2018 11:59 PM, Norman Maurer wrote: >> Hi all, >> >> While working on some unit tests

Re: Possible bug in SSLEngine / SSLSession implementation

So is what I see something that should be fixed in general ? Like I said it does not matter if its TLSv1.3 or earlier. Bye Norman > On 12. Dec 2018, at 15:42, Norman Maurer wrote: > > Hi Jamil, > > This was just noticed during a test which uses TLS1.2. > >> O

SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

Hi all, I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(…) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itsel

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

Any comments here ? Bye Norman > On 28. Feb 2019, at 09:24, Norman Maurer wrote: > > Hi all, > > I think I found a possible regression / bug in the latest JDK12 release when > trying to upgrade the Netty CI server to test with the latest JDK12 release. > The problem i

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

Is there anything else I can do to have anyone look into this? I just want to make sure this does not fall through before the final JDK 12 release is done. Bye Norman > On 4. Mar 2019, at 21:15, Norman Maurer wrote: > > Any comments here ? > > Bye > Norman > > &

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

As it contains also keymaterial can I just tar it or will you be able to use your own keymaterial and fill in the missing pieces? Bye Norman > On 13. Mar 2019, at 08:48, Alan Bateman wrote: > > On 13/03/2019 06:31, Norman Maurer wrote: >> Is there anything else I can do to h

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

> > Xuelei, would you have time to look at this? > > Thanks, > Sean > > On 3/13/19 2:31 AM, Norman Maurer wrote: >> Is there anything else I can do to have anyone look into this? >> I just want to make sure this does not fall through before the final JDK 12 >&

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

(!o1.equals(o2)) { throw new AssertionError(o1 + " != " + o2); } } } > On 13. Mar 2019, at 10:04, Alan Bateman wrote: > > On 13/03/2019 07:51, Norman Maurer wrote: >> As it contains also keymaterial can I just tar it or will you be able to use >> your ow

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

> What's the problem in the application? It is possible that status is > NOT_HANDSHAKING even there are bytes left that should be consumed, for > example alert or application data. NOT_HANDSHAKING means that the > handshaking is not in progress. > > Thanks, > Xuel

Re: Use of OpenSSL as JCE security provider if available on system

Actually this is not based on OpenSSL but it uses BoringSSL (which provides an OpenSSL API + some extra stuff), just in case it matters for anyone. Bye Norman > On 15. Mar 2019, at 17:37, Simone Bordet wrote: > > Hi, > > On Fri, Mar 15, 2019 at 3:28 PM Darran Lofthouse > wrote: >> FYI if an

Possible bug with JDK12 and ChaCha ciphers

Hi there, We recently received a bug report in netty when JDK12 is used with ChaCha chiphers: https://github.com/netty/netty/issues/9150 Basically it seems like there is a problem in how it uses the ByteBuffer internally: Caused by: java.lang.Run

Re: Possible bug with JDK12 and ChaCha ciphers

reproduce this issue, would you mind post the JSSE debug > log (by using Java System Property, "javax.net.debug=all")? > > Please feel free to submit a bug. > > Thanks & Regards, > Xuelei > > On 5/17/2019 11:02 AM, Norman Maurer wrote: >> Hi there, >&

Re: Possible bug with JDK12 and ChaCha ciphers

The user did capture the log here: https://hasteb.in/ucalevob.makefile <https://hasteb.in/ucalevob.makefile> Hopefully it is helpful, Norman > On 17. May 2019, at 20:38, Norman Maurer wrote: > > Unfortunately I am very busy atm so it may take me a few days. I asked the >

Re: Possible bug with JDK12 and ChaCha ciphers

Hi there, Did the debug log help at all or should I try to gather more informations from the user ? Bye Norman > On 17. May 2019, at 21:26, Norman Maurer wrote: > > The user did capture the log here: > > https://hasteb.in/ucalevob.makefile <https://hasteb.in

Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

Hi there, I am just about to add JDK14 to the test matrix for netty and think I found a regression. Before I will invest time to write a standalone reproducer please let me know if you think this is a regression or not. Basically after the handshake is complete SSLEngine.getSession().getSession

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

ey wrote: > > Looks interesting Norman. Do you want to share some more details about the > peculiarities of this handshake before considering a fully fledged testcase ? > > regards, > Sean. > > On 27/03/2020 12:48, Norman Maurer wrote: >> Hi there, >> >> I am j

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

d SSL server regardless of the property value on > the server side. > > Thanks, > > --Jamil > > On 3/30/2020 5:31 AM, Norman Maurer wrote: >> Hey Sean, >> >> There is not much to share as its just a simple handshake :) >> >> Anyway here is a rep

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

t; it doesn't always happen. Still working on characterizing it. > > --Jamil > > On 3/31/2020 7:11 AM, Norman Maurer wrote: >> Yes thats about right… if setting to false it works as expected. >> >> >> Bye >> Norman >> >> >>

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

wse/JDK-8242008 > <https://bugs.openjdk.java.net/browse/JDK-8242008> > --Jamil > > On 4/1/2020 12:32 AM, Norman Maurer wrote: >> Please add a link to the bug once it is created. >> >> Bye >> Norman >> >> >>> On 31. Mar 2020, at 1

"Blocking operation" during SSLEngineImpl.unwrap()

Hi there, In netty we support using BlockHound[1] to detect if people do blocking operations within the EventLoop and so notify them that this should not be done. While running our integration tests with TLS1.3 we noticed that unwrap(…) may trigger an FileInputStream.read(…) which in theory cou

Re: "Blocking operation" during SSLEngineImpl.unwrap()

i > > On 8/7/2020 5:00 AM, Norman Maurer wrote: >> Hi there, >> In netty we support using BlockHound[1] to detect if people do blocking >> operations within the EventLoop and so notify them that this should not be >> done. While running our integration tests

Re: "Blocking operation" during SSLEngineImpl.unwrap()

I think the possibility that it may block should be enough to signal and so offload to a task. If it never blocks then it’s not a bug... that’s why I asked the question in the first place . Bye Norman > Am 07.08.2020 um 18:13 schrieb Alan Bateman : > > On 07/08/2020 16:00, Xuelei Fan wrote:

Re: [TLS-backport8] Does TLSv1.3 work with www.google.com

Just FTW I think they still enable the TLS1.3 detection logic via their BoringSSL usage just like others noted: https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_set_jdk11_workaround

Re: "Blocking operation" during SSLEngineImpl.unwrap()

Not that I am aware of. I will look into it later this week again and report back. Bye Norman > On 18. Aug 2020, at 02:21, Bradford Wetmore > wrote: > > > Hi Norman, > > There are a couple things in the stack trace that don't make sense. Am I > missing something? > > This looks like a s

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

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 c

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

Submitted it via https://bugreport.java.com <https://bugreport.java.com/>. Please let me know once it “transferred” to https://bugs.openjdk.java.net <https://bugs.openjdk.java.net/> Bye Norman > On 10. Jul 2018, at 20:26, Norman Maurer wrote: > > Will do tomorrow la

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

avi 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

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

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 re

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

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 thes

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

lable, 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 probl

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

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, >> >>

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

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 whe

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

> 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 th

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

I there any idea when the patch will be merged and a release will be cut so we can enable testing with JDK11 again for netty ? > On 31. Jul 2018, at 07:19, Norman Maurer wrote: > > After digging more this morning I noticed the test code did made some wrong > assumptions which jus

Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well

Hi all, Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implem

Re: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well

are still using the X509TrustManager > implementation? > > Thanks, > Xuelei > >> On 9/11/2018 3:32 AM, Norman Maurer wrote: >> Hi all, >> Would it be possible to consider exposing >> SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible &

TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

Hi all, I am currently in the process of adding TLS 1.3 support into netty-tcnative[1] which uses JNI to make use of OpenSSL for it. During this work I noticed that I received test-failures when mutual auth is used and the JDK implementation is used on the client side. When using the JDK implem

Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

Is there any more details you need ? Just wondering. If you say so I can also provide a pure jdk client (without the Netty wrapper) that shows the problem when used with OpenSSL on the server in the next days. Bye Norman > Am 13.09.2018 um 21:07 schrieb Norman Maurer : > > Hi all,

Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

t;> On 9/14/2018 10:29 PM, Norman Maurer wrote: >> Is there any more details you need ? >> Just wondering. If you say so I can also provide a pure jdk client (without >> the Netty wrapper) that shows the problem when used with OpenSSL on the >> server in the next days. >&

Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

ible that it isn't properly selecting an entity to use, in which case an > empty message will be sent. > > Brad > > >> On 9/14/2018 11:18 PM, Norman Maurer wrote: >> Ok will try to find time today. >>> Am 15.09.2018 um 08:08 schrieb Xuelei Fan : >&

Re: [External] : Re: SSLEngine.unwrap on read-only input ByteBuffer

I agree with Chris here that doing in-place modification of the source buffer is really surprising even if it’s not read-only. This really sounds like something I would consider a „breaking change“ as I can’t imagine users would expect this at all (nothing was ever in the javadocs that would sug

Bug with TLSv1.3 session resumption (most likely caused by concurrency bug)

Hi there, I think I found a bug in the TLSv1.3 session cache implementation which sometimes can cause failures during session resumption. The cause of this sometimes show up as NPE: javax.net.ssl.SSLException: Session has no PSK at java.base/sun.security.ssl.Alert.createSSLException(Ale

Re: Bug with TLSv1.3 session resumption (most likely caused by concurrency bug)

>> On 3/4/2021 8:22 AM, Xue-Lei Fan wrote: >> Forward to security-dev. >> >> Xuelei >> >>> On Mar 4, 2021, at 6:11 AM, Norman Maurer >>> wrote: >>> >>> Hi there, >>> >>> I think I found a bug in the TLSv1.3 ses

Re: [External] : Re: Bug with TLSv1.3 session resumption (most likely caused by concurrency bug)

ple other bugs, but I should have some time > to devote to it next week. > > --Jamil > > On 3/19/2021 6:15 AM, Norman Maurer wrote: >> I was wondering if there is any update or anything I can help with ? >> >> Bye >> Norman >> >>>

Re: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93)

On Fri, 23 Apr 2021 20:51:19 GMT, Alexey Bakhtin wrote: > Hello All, > > Could you please review the fix for the JDK-8241248? > The issue happens during the TLSv1.3 handshake without server stateless > session resumption in case of server receives several parallel requests with > the same pre_