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
<
http://openjdk.5641.n7.nabble.com/Issues-with-ALPN-implementation-in-JDK-9-tt274952.html#a275096>,
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
<
https://www.mail-archive.com/search?l=security-dev@openjdk.java.net&q=subject:%22Re%5C%3A+Issues+with+ALPN+implementation+in+JDK+9%22&o=newest&f=1>,
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:
1. Hello frame arrives and is parsed (no library code for this but is
simple enough)
2. With knowledge of the protocols & ciphers offered in the Hello, the
available ciphers of the SslEngine may be trimmed/customized.
3. The SslEngine unwraps the Hello frame and selects a specific cipher
and SNI based on available ciphers and certificates.
4. With knowledge of the offered protocols, negotiated cipher, selected
SNI/Certificate a protocol can be selected and set on the SslEngine.
5. 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