[wildfly-dev] HTTP/2 out of the box in Wildfly 10.1

[Stuart Douglas]

You are always going to be able to MITM with self signed certs though,
dynamically generated or not.

Stuart

On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse <darran.lofthouse at jboss.com
> wrote:

> Not a fan of dynamically generated self signed certificates - a recipe
> for leading users into shooting themselves in the foot.
>
> I say that after witnessing myself a user tricking themselves with their
> own man in the middle attack.
>
> Darran.
>
>
> On 02/06/16 00:22, Stuart Douglas wrote:
> > Hi All,
> >
> > I would like to propose that we add support for HTTP/2 out of the box in
> > Wildfly 10.1.
> >
> > At the moment there are two main barriers to getting HTTP/2 two work:
> >
> > - You need to set up a HTTPS connector, including generating keys etc.
> > For new users this is not as straightforward as it could be.
> > - You need to find the correct version of the Jetty ALPN jar and add it
> > to your boot class path. This is essentially a hack that modifies the
> > JDK SSL classes to allow them to support ALPN. A new version is needed
> > for every JDK8 release, so if you ever update the JVM HTTP/2 will stop
> > working (JDK9 has support for ALPN so this is not nessesary).
> >
> > I am proposing that we do the following to address these issues:
> >
> > - Add support for lazily generated self signed certificates, and include
> > this in the default config. This would mean that we would have a working
> > HTTPS connector in the default config, although the first request would
> > be a bit slow as it would need to generate a new self signed certificate
> > for localhost. This allows for SSL out of the box, without any impact on
> > startup time or any need for an installer to generate the certificate.
> >
> > - I have dealt with the ALPN issue in Undertow using a reflection based
> > hack. I have created some code that parses and modifies the SSL
> > Server/Client hello messages to add/read APLN information, and I then
> > use reflection to update the HandshakeHash maintained by the engine so
> > the engines internal hash state used to generate the Finished frames
> > matches the data that was actually sent over the wire.
> >
> > Yes I am aware that this is a massive hack, however I think it is
> > preferable to the current boot classpath hack, which has a lot of a
> > drawbacks. If this ever stops working at some point due to internal JDK
> > changes the boot classpath hack would still be usable, however I don't
> > think this is particularly likely, as the part of the JDK that this
> > modifies seems unlikely to change.
> >
> > I think this would be a great usability feature, allowing developers to
> > get started with HTTPS and HTTP/2 straight away.
> >
> > Thoughts?
> >
> > Stuart
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/183c2662/attachment.html