On Fri, Jul 29, 2016 at 12:45 PM, Greg Wilkins <gregw_at_webtide.com> wrote:
>
> 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.
My question was basically why do you need to discard the first
SslEngine if it comes up with an acceptable protocol+cipher combo
(which should be the case the majority of the time).
Stuart
>
> 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