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

[Jason T. Greene]

IMO it's no different than ssh keys. Also we could just leave localhost as the default bind, and they are likely to add the browser exception before moving the bind address. 

> On Jun 2, 2016, at 6:04 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> The dynamically generated is the worst part of it though as they have no certificate information to compare when the browser complains.
> 
> Probably not the end of the world though, we will still be able to guide them in the future to do it properly.  Location wise I think we should see if the generation can be wrapped in the legacy security realms to minimise compatibility issues once we get to WildFly 11.
> 
> Darran.
> 
> 
> 
> ----- Original Message -----
> From: "Stuart Douglas" <stuart.w.douglas at gmail.com>
> To: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Thursday, 2 June, 2016 11:38:04 AM
> Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
> 
> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev