Re: Issues with ALPN implementation in JDK 9

On 6/15/2016 1:35 AM, Simone Bordet wrote: We have not heard from Oracle yet, but I can prepare a webrev if that helps. Hi all, Nice to see different folks are trying things out. I do appreciate the discussion/feedback. I am on a high-priority project right now, so I haven't had a chance

Re: Issues with ALPN implementation in JDK 9

On 15 June 2016 at 21:31, David M. Lloyd wrote: > > >> I am proposing 3 simple changes to be done: >> >> 1) Introduce a TLSProtocolNames class that can convert from TLS >> protocol bytes to TLS protocol names. >> 2) Introduce a TLSCipherSuiteNames class that can convert from TLS >> cipher suite by

Re: Issues with ALPN implementation in JDK 9

> On Jun 15, 2016, at 2:25 PM, Simone Bordet wrote: > > Hi, > > On Wed, Jun 15, 2016 at 8:12 PM, Jason Greene wrote: >> Here is an H2 example: >> >> The ClientHello expressing interest in both h2, and h1, and lists the >> ciphers: >>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 >>TLS_ECDHE_R

Re: Issues with ALPN implementation in JDK 9

Hi, On Wed, Jun 15, 2016 at 8:12 PM, Jason Greene wrote: > Here is an H2 example: > > The ClientHello expressing interest in both h2, and h1, and lists the ciphers: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > So in this case the client is expressing

Re: Issues with ALPN implementation in JDK 9

> On Jun 15, 2016, at 7:07 AM, David M. Lloyd wrote: > > On 06/14/2016 09:28 PM, Greg Wilkins wrote: >> >> >> On 15 June 2016 at 11:40, Jason T. Greene > > wrote: >> >> >>> On Jun 14, 2016, at 7:04 PM, Greg Wilkins > > wrote: >>

Re: Issues with ALPN implementation in JDK 9

On 06/15/2016 07:36 AM, Simone Bordet wrote: Hi, On Wed, Jun 15, 2016 at 1:31 PM, David M. Lloyd wrote: The problem is that this is quite subjective. In my opinion the current solution is both clean and precise: 1) Read the hello packet 2) Examine the protocols, host names, and cipher suites

Re: Issues with ALPN implementation in JDK 9

Hi, On Wed, Jun 15, 2016 at 1:31 PM, David M. Lloyd wrote: > The problem is that this is quite subjective. In my opinion the current > solution is both clean and precise: > > 1) Read the hello packet > 2) Examine the protocols, host names, and cipher suites > 3) Apply arbitrary user policy to se

Re: Issues with ALPN implementation in JDK 9

On 06/14/2016 09:28 PM, Greg Wilkins wrote: On 15 June 2016 at 11:40, Jason T. Greene mailto:[email protected]>> wrote: > On Jun 14, 2016, at 7:04 PM, Greg Wilkins mailto:[email protected]>> wrote: > > If SslEngine is changed to allow the negotiated application protocol to

Re: Issues with ALPN implementation in JDK 9

On 06/15/2016 03:35 AM, Simone Bordet wrote: Hi, On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley wrote: The problem I have with reading posts about JDK9 problems is that I can't tell the *severity* of the problems. I don't know if something is a total blocker or an inconvenience. When someone

Re: Issues with ALPN implementation in JDK 9

Hi, On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley wrote: > The problem I have with reading posts about JDK9 problems is that I > can't tell the *severity* of the problems. I don't know if something > is a total blocker or an inconvenience. When someone uses an internal > sun.* class they may b

Re: Issues with ALPN implementation in JDK 9

On 15/06/16 09:11, Simone Bordet wrote: > Sure, but then every ALPN implementer out there will have their own, > they will need to be kept up to date when a new TLS protocol or a new > cipher is introduced in the JDK, etc. etc. OK, I get that. The problem I have with reading posts about JDK9 prob

Re: Issues with ALPN implementation in JDK 9

Hi, On Wed, Jun 15, 2016 at 10:03 AM, Andrew Haley wrote: > On 14/06/16 14:57, Simone Bordet wrote: >> * Lack of facilities to convert TLS protocol bytes to protocol strings. >> This class already exist in JDK, sun.security.ssl.ProtocolVersion, it >> would just need to be exposed in javax.net.ssl

Re: Issues with ALPN implementation in JDK 9

On 14/06/16 14:57, Simone Bordet wrote: > * Lack of facilities to convert TLS protocol bytes to protocol strings. > This class already exist in JDK, sun.security.ssl.ProtocolVersion, it > would just need to be exposed in javax.net.ssl. > > * Lack of facilities to convert TLS cipher bytes to cipher

Re: Issues with ALPN implementation in JDK 9

On 15 June 2016 at 11:40, Jason T. Greene wrote: > > > > On Jun 14, 2016, at 7:04 PM, Greg Wilkins wrote: > > > > If SslEngine is changed to allow the negotiated application protocol to > be set up until the time the hello response was wrapped, that would fix the > problem. Would it create any o

Re: Issues with ALPN implementation in JDK 9

> On Jun 14, 2016, at 7:04 PM, Greg Wilkins wrote: > > If SslEngine is changed to allow the negotiated application protocol to be > set up until the time the hello response was wrapped, that would fix the > problem. Would it create any others? Well the fundamental issue is that the applica

Re: Issues with ALPN implementation in JDK 9

I think this discussion can be simplified to the following points: - ALPN allows for a negotiated application protocol to be a function of the cipher negotiated ( h2 vs h1 selection being the prime use-case). - The cipher is negotiated by SslEngine during the unwrap of the Hello messag

Re: Issues with ALPN implementation in JDK 9

> On Jun 14, 2016, at 2:52 PM, Simone Bordet wrote: > > Hi, > > On Tue, Jun 14, 2016 at 8:11 PM, Jason Greene wrote: >> If the case is that H3 blacks all RSA, then thats an easy test right? Just >> verify that keystore has an ECDSA key. > > I don't think it is that easy. Well certificate me

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 8:11 PM, Jason Greene wrote: > If the case is that H3 blacks all RSA, then thats an easy test right? Just > verify that keystore has an ECDSA key. I don't think it is that easy. The server logic has to mimic exactly what the JDK logic is, that is to verify the ciphe

Re: Issues with ALPN implementation in JDK 9

> On Jun 14, 2016, at 10:58 AM, Simone Bordet wrote: > > Hi, > > On Tue, Jun 14, 2016 at 5:26 PM, Jason T. Greene > wrote: >> With H2 all impls are required to support >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > Unless it is discovered vulnerable. Sure, but in that case we have to rev the

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 5:58 PM, Simone Bordet wrote: > The server could choose an ECDSA cipher for h3, the mandatory cipher > for h2, so the list of cipher is (ECDSA, RSA). If, at this point, the > server chooses the protocol *before* the JDK chooses the cipher, it > may think that h3 is a g

Re: Issues with ALPN implementation in JDK 9

Hi, i think not only the cipher suite and protocol version. But many other parts should be also be public. Like Supported digest, curve types, etc... And also these information should be available for the keymanger. So that he is able to select certificate also based on the curve types. Gruß T

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 5:26 PM, Jason T. Greene wrote: > With H2 all impls are required to support > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Unless it is discovered vulnerable. > so that should be selectable either by your protocol stack or the TLS layer. > If you wanted to be especially

Re: Issues with ALPN implementation in JDK 9

> On Jun 14, 2016, at 8:58 AM, Simone Bordet wrote: > > During the unwrap(), the JDK implementation picks a cipher based on > the JDK logic. > In particular, in my case, I had a keystore with a certificate that > was *not* ECDSA. > If, in the snippet above, I set more than one cipher on the > S

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 4:53 PM, David M. Lloyd wrote: > Yes. Basically the server logic always has to be up to date with the latest > cipher suites and that sort of thing. Our solution to this is to have a > security framework that is responsible for this (among other things). It's > not

Re: Issues with ALPN implementation in JDK 9

On 06/14/2016 09:47 AM, Simone Bordet wrote: Hi, On Tue, Jun 14, 2016 at 4:31 PM, David M. Lloyd wrote: During the unwrap(), the JDK implementation picks a cipher based on the JDK logic. In particular, in my case, I had a keystore with a certificate that was *not* ECDSA. Could you not use th

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 4:31 PM, David M. Lloyd wrote: >> During the unwrap(), the JDK implementation picks a cipher based on >> the JDK logic. >> In particular, in my case, I had a keystore with a certificate that >> was *not* ECDSA. > > Could you not use the available keys as an input into

Re: Issues with ALPN implementation in JDK 9

I have a few questions, inline. On 06/14/2016 08:57 AM, Simone Bordet wrote: Hi, I gave a shot at implementing ALPN in JDK 9 in Jetty. TLDR: I could not find a way to make it work. This email is to discuss whether I am off road or discuss possible solutions. Below my feedback. * Lack of faci