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