jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] Re: Re: Re: Servlet 4.0 and ALPN

From: Greg Wilkins <gregw_at_webtide.com>
Date: Fri, 29 Jul 2016 12:45:42 +1000

Stuart,

the process to negotiate a cipher is rather complex and relies on:

   - ciphers offered
   - ciphers available
   - certificates available, including signing their signing algorithms
   - SNI names of the certificates and their alternative names

This is all done by SslEngine in an extensible way that will be updated
with new ciphers and certificates over time. All good so far!

But ALPN/HTTP2 require us to consider the negotiated cipher when selecting
a protocol. It may be that whilst h2 is on offer and acceptable, the SNI
caused a particular certificate to be used that forced a cipher selection
that was unacceptable to h2, and thus http1 needs to be selected.

So in order to make the protocol selection, we need to know the selected
cipher. But the problem is that with the current SslEngine
implementation, if you allow it to select a cipher (by unwrapping the
hello), then it is too late to set your protocol selection.

The current solution we are considering is to create 2 SslEngines. We
unwrap the hello frame in the first SslEngine and see what cipher it
selects. We then discard that SslEngine, configure the 2nd SslEngine with
our choice of protocol and replay the Hello frame to the 2nd Engine. It
now selects the same cipher again and can send a hello response with our
selected protocol.

The alternate solution, which I believe Redhat are going for, is to
duplicate all the cipher selection logic themselves, which sounds like a
maintenance nightmare to me, as they will need to maintain forever to track
new ciphers and certificates and ensure they never make a different choice
to the SslEngine - Ugh!

The real solution is for Oracle to start listening and to make a small
patch to SslEngine to allow the protocol to be change up until the Hello
response is wrapped. Only then can we fully implement the h2
requirements to select a protocol considering which cipher is negotiated.

Once we have that logic settled for 9, we can then see what we can do to
implement in 8 - replacing our current partial solution.

regards















On 29 July 2016 at 12:03, Stuart Douglas <sdouglas_at_redhat.com> wrote:

> Why would you need two SslEngines per connection? Won't that situation
> only arise if the initial negotiation resulted in an invalid
> combination (which I think should be very rare in practice, as
> clients/servers that do not have strong ciphers should not be
> advertising h2 anyway)?
>
> I do agree with you that the current situation is not ideal.
>
> Stuart
>
> On Fri, Jul 29, 2016 at 11:01 AM, Greg Wilkins <gregw_at_webtide.com> wrote:
> >
> > All,
> >
> > Ideally we need a solution for java8 that will allow us to move our
> > implementations towards what will be available in java9.
> >
> > Unfortunately even the ALPN solution provided in java9 is looking like it
> > has problems and the Jetty team has been trying to get some
> consideration,
> > but without much success.
> >
> > So while I think that an 8.1 with ALPN support would be great, we really
> > need to push oracle for a workable solution in 9 that can be the target
> of
> > further efforts to improve ALPN in 8 (or 8.1).
> >
> > The issue in java 9 is where the intercept points are. In order to
> > implement their ALPN support, you need to parse the TLS hello message
> > yourself to determine the offered protocols. However, the selection of
> > which protocol to accept cannot be done in isolation, as the HTTP2 spec
> > requires consideration of the cipher that is negotiated as well. The
> > negotiated cipher is only known after you allow the SslEngine to also
> parse
> > the Hello message. So that's a good point to insert your http2 logic
> to
> > look at both the protocols offered and the cipher negotiated in order to
> > select the protocol before sending the Hello response.
> >
> > Unfortunately the current implementation of SslEngine does not allow the
> > negotiated protocol to be set after the Hello has been unwrapped but
> before
> > the response has been wrapped. This means that as well has parsing the
> > Hello message yourself, you have to duplicate the SslEngine logic to work
> > out which cipher it is going to select (including any SNI and certificate
> > considerations which can be complex and forever changing), before calling
> > the SslEngine. This is needless duplication of effort and will be
> > exceedingly fragile (unless you use two copies of SslEngine for every
> > connection!).
> >
> > The Oracle team appear to busy on other matters to give this important
> issue
> > proper consideration, but have said they will try, but no result yet.
> >
> > I fear we are sleep walking into a poor JDK9 solution that will cause
> > portability problems. I think we really need to sort that out as our
> > highest priority. Once we have a good target in 9, then we can lobby to
> > have a similar solution in 8.1 or come up with agents or other patches
> that
> > provide similar logic.
> >
> > For clarity, this is the handshake process we would like to see:
> >
> > Hello frame arrives and is parsed (no library code for this but is simple
> > enough)
> > With knowledge of the protocols & ciphers offered in the Hello, the
> > available ciphers of the SslEngine may be trimmed/customized.
> > The SslEngine unwraps the Hello frame and selects a specific cipher and
> SNI
> > based on available ciphers and certificates.
> > With knowledge of the offered protocols, negotiated cipher, selected
> > SNI/Certificate a protocol can be selected and set on the SslEngine.
> > The SslEngine wraps the Hello frame response with the results of all the
> > negotiations.
> >
> >
> > regards
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 29 July 2016 at 09:30, Stuart Douglas <sdouglas_at_redhat.com> wrote:
> >>
> >> I actually have another (very hacky) ALPN implementation that will be
> >> part of Wildfly 10.1. At the moment it works on Oracle JDK's (I have
> >> not looked into getting it to work on IBM).
> >>
> >> Basically it works by modifying the handshake that is sent over the
> >> wire by manually parsing and modifying the TLS frames, and then using
> >> reflection to update the engines internal hash state to match what was
> >> actually sent over the wire (like I said, very hacky).
> >>
> >> The advantage of this approach is that as long as the SSLEngine
> >> internals do not change too much it works across different versions of
> >> the Oracle JDK and does not require modifying the boot class path. The
> >> major disadvantage is that it is possible that a future JDK update
> >> could break this (and potentially break it in a way that it cannot be
> >> fixed), which makes it very problematic from a support point of view.
> >>
> >> Stuart
> >>
> >> On Fri, Jul 29, 2016 at 12:08 AM, Martin Mulholland <
> mmulholl_at_us.ibm.com>
> >> wrote:
> >> > We have been discussing ALPN support for Servlet 4.0 here at IBM and
> do
> >> > not
> >> > consider the current solution acceptable. A reasonable option would be
> >> > to
> >> > provide a Java 8.1 release which includes ALPN support which Servlet
> 4.0
> >> > would then require. I strongly recommend that this is considered by
> >> > Oracle.
> >> >
> >> > The current solution employed by Jetty works for the most part but is
> >> > problematic,
> >> > 1. The OpenJDK patch needs to be rebuilt and then re-installed by
> >> > customers
> >> > for every new JDK version. This creates a significant service
> overhead.
> >> > 2. Different patches will be needed for other JDK's. IBM could provide
> >> > one
> >> > for the IBM JDK, what Oracle will do is not known.
> >> > 3. The Jetty OpenJDK patch has dependencies on Jetty code and as a
> >> > result is
> >> > not re-usable by other providers. Requiring each provider to provide
> >> > their
> >> > own set of patches is asking a lot. Not even sure if it would be
> legal,
> >> > for
> >> > example, for IBM to provide a patch for the Oracle JDK which must then
> >> > be
> >> > installed to run Liberty. It is also Also not clear how other provides
> >> > can
> >> > support the IBM JDK.
> >> > 4. Need to understand how the Servlet 4.0 TCK will test secure use of
> >> > the
> >> > push api running on Java8.
> >> >
> >> > We could alleviate 3. by agreeing to a common api which container
> >> > providers
> >> > implement and which is then used by all of the JDK patches created
> but
> >> > that
> >> > still does not make this a workable solution.
> >> >
> >> > Thank you,
> >> > Martin Mulholland.
> >> > WebSphere Application Server Web Tier Architect
> >> > email: mmulholl_at_us.ibm.com
> >> >
> >> > IBM RTP, PO BOX 12195, 503/C227,
> >> > 3039 Cornwallis Rd, RTP, NC 27709-2195
> >> > t/l 444-4319, external (919)-254-4319
> >> >
> >> >
> >> >
> >> >
> >> > From: Mark Thomas <markt_at_apache.org>
> >> > To: jsr369-experts_at_servlet-spec.java.net
> >> > Date: 07/13/2016 05:10 PM
> >> > Subject: [servlet-spec users] [jsr369-experts] Re: Servlet 4.0
> >> > and
> >> > ALPN
> >> > ________________________________
> >> >
> >> >
> >> >
> >> > On 13/07/2016 22:41, Martin Mulholland wrote:
> >> >> Section 1.2 of the Servlet 4.0 spec states that, to support HTTP/2,
> >> >> there is an implied requirement to support APLN. This is consistent
> >> >> with the HTTP/2 RFC. In the same section it also states a requirement
> >> >> to
> >> >> support Java SE 8 which is consistent with the Java EE 8 requirement
> >> >> for
> >> >> Java SE 8. However ALPN support is currently planned for Java SE 9
> and
> >> >> is not part of Java SE 8.
> >> >>
> >> >> Are there any plans to backport ALPN to Java SE 8 or are we expecting
> >> >> container providers to provide their own, or an open source, version
> of
> >> >> ALPN? Thank you,
> >> >
> >> > Short version: The EG asked Oracle for a back-port. Oracle refused.
> >> >
> >> > Long version:
> >> >
> >> >
> https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2014-11/message/7
> >> >
> >> > I believe Jetty has a JRE point release specific patches to back-port
> >> > ALPN support.
> >> >
> >> > Tomcat requires that OpenSSL is used (either via the APR/native
> >> > connector or via the OpenSSL JSSE 'implementation') for ALPN (and
> hence
> >> > HTTP/2) support.
> >> >
> >> > Mark
> >> >
> >> >
> >> >
> >> >
> >
> >
> >
> >
> > --
> > Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>



-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com