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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev