jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: ALPN status: Java SE 9 and JDK 8

From: Stuart Douglas <sdouglas_at_redhat.com>
Date: Tue, 18 Apr 2017 09:08:53 +1000

In this case I don't really think we should be requiring HTTP/2
support if the underlying JDK does not support it.

Basically at the moment AFAIK there are the following ways to support
ALPN, and all of them have issues:

1) Override the boot class path (Jetty ALPN, and the proposed Oracle solution):

This is very problematic because it requires a new version for each
JDK update. In general using the wrong version will start fine, but
then attempting SSL connections will cause problems. It also
introduces security concerns as if a SSL bug is found in the code that
is replaced it is theoretically possible that an older version could
work on a newer JDK, however override the security fix present in the
newer version would not be present (i.e. even if it is compatible
across releases, you will still be running the old code).

2) OpenSSL:

This requires a newish OpenSSL to be installed on the host, as well as
native bindings to act as the bridge to OpenSSL. This uses native code
and is platform dependent, so it is not really something that will
work out of the box in every situation.

3) Undertow reflection hack

This is Undertow's default implementation and works on all released
Oracle/OpenJDK 8 versions, however as it hacks into the JDK internals
it could break in a future release. The classes in question have not
changed in a while, and the chances are it will continue to work over
the lifetime of JDK8 however this is not something we can guarantee.

4) Implement support through a javaagent (theoretical)

In theory you could do something similar to 1) using a javaagent
rather than replacing the boot class path, which could give you better
compatibility across JVM versions, although AFAIK no one has attempted
this yet.



With the exception of OpenSSL all of these are basically hacks, and
OpenSSL relies on native code and a 3rd party product. Do we really
want to require that all Servlet 4.0 compliant containers will have to
support one of these?

As I understand the TCK rules this requirement would mean that
containers should support HTTP/2 in their default configuration in
order to be compliant, which is not really possible with a lot of
these solutions (although I am not 100% sure on this).

Stuart

On Tue, Apr 18, 2017 at 8:08 AM, Edward Burns <edward.burns_at_oracle.com> wrote:
> Hello Volunteers,
>
>>>>>> On Fri, 9 Dec 2016 10:01:34 -0800, Edward Burns <edward.burns_at_oracle.com> said:
>
> EB> Here's the latest on the ALPN issue. As we discussed at the 2016-11-01
> EB> meeting, work will proceed on two fronts, the Java SE 9 front and the
> EB> JDK 8 front.
>
> Sigh.
>
> EB> I'd like to extend a special thanks to Vinnie to spearheading this
> EB> vitally important work. It goes a long way to help the Java community,
> EB> and especially the community of Servlet 4 implementers.
>
> I'm still thanks to Vinnie for his help.
>
> EB> Java SE 9
> EB> =========
>
> EB> Just yesterday Vinnie sent this to security-dev:
>
> EB> http://mail.openjdk.java.net/pipermail/security-dev/2016-December/015266.html
>
> EB> I'll pass along his appeal here:
>
> Work is proceeding apace here. Thanks to everyone who helped on it.
>
> EB> JDK 8
> EB> =====
>
> [...]
>
> EB> We cannot give any commitment on delivery dates for this in JDK 8, but
> EB> it will certainly depend on the JDK 8 Update schedule and security team
> EB> priorities.
>
> EB> Thanks for your patience.
>
> Unfortunately, I don't have good news here. Those priorities are
> outside of our control and a definitive decision has been taken to not
> pursue the backport to JDK 8 as we discussed late last year and early
> this year. As a consolation, we are making available the JDK 1.8.0_121
> specific solution we are using for the Grizzly based GlassFish 5.0 RI,
> as detailed in this message from Java EE Architect Bill Shannon:
>
>>>>>> On Mon, 17 Apr 2017 13:51:45 -0700, Bill Shannon said:
>
> B> The Servlet 4.0 specification intended for Java EE 8 includes support
> B> for the HTTP/2 standard, which requires an implementation of ALPN.
> B> ALPN support is included in the SSL/TLS implementation in JDK 9. Given
> B> that Java EE 8 should be supported on JDK 8, we understand that it will
> B> be beneficial for Java EE licensees to have ALPN available in JDK 8.
> B> Oracle is focused on JDK 9 and JDK 10 at this time and has no plans to
> B> backport new major features in critical patch updates.
>
> B> We understand that some of the Java EE licensees have already created
> B> workarounds to have HTTP 2.0 work with JDK 8. A typical workaround is
> B> to modify some classes from JDK 8 to support ALPN, and then to use them
> B> to effectively "patch" JDK 8 with these new APIs and implementation.
> B> Since the Oracle Binary Code License prevents replacing or overriding
> B> arbitrary classes in the Oracle JDK, Oracle intends to make changes for
> B> the upcoming JDK 8 critical patch update to allow overriding these
> B> SSL/TLS implementation classes.
>
> B> Oracle will also provide a replacement SSL/TLS implementation as a
> B> "patch" that can be applied to this version of JDK 8 that will provide
> B> the required ALPN support needed by the Servlet reference
> B> implementation. This patch will be provided as a part of the Java EE
> B> reference implementation and can be used by licensees and end users.
> B> This patch would be applied using something like -Xbootclasspath or
> B> some equivalent OSGi mechanism so that these classes override the
> B> classes included in the JDK without modifying the JDK itself. Licensees
> B> may need to create their own patch or modify the reference implementation
> B> patch to meet the needs of their product.
>
> B> Given that the JDK 9 release is imminent, we expect that the workaround
> B> will suffice for the lifespan of JDK 8 deployments. We expect most
> B> Java EE implementations to move to JDK 9 quickly, and some may never
> B> need to support JDK 8. We do understand you might be worried about
> B> the additional risk you are taking on by use of copied/non-public
> B> APIs and we will do our best to communicate to Java EE licensees any
> B> significant changes to these SSL/TLS implementation classes in future
> B> JDK updates.
>
> Bottom line, in spite of our best efforts, ALPN support remains an
> implementation detail for Servlet 4.0 implementations.
>
> Sincerely,
>
> Ed and Shing-wai Chan
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 4 business days until planned start of Servlet 4.0 Public Review