Have not seem anything on this since Stuart raised the issue. Have there
been any additional (private) conversations on this topic? Like Stuart,
we consider this ALPN solution as a hack. But, if we consider Stuart's
suggestion of not requiring secure http/2 in Servlet 4, would that mean to
make it optional? Or, would we consider removing it altogether from
Servlet 4? Any of these approaches would affect the TCK/CTS testing of
Servlet 4. Any possible change in direction here would definitely affect
our plans going forward and we'd like to close on this issue.
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
Stuart Douglas <sdouglas_at_redhat.com> wrote on 04/17/2017 07:08:53 PM:
> From: Stuart Douglas <sdouglas_at_redhat.com>
> To: jsr369-experts_at_servlet-spec.java.net
> Cc: Vincent Ryan <vincent.x.ryan_at_oracle.com>
> Date: 04/17/2017 07:10 PM
> Subject: [servlet-spec users] [jsr369-experts] Re: ALPN status: Java
> SE 9 and JDK 8
>
> 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
Oraclesolution):
>
> 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
>