<div dir="ltr"><div>You are always going to be able to MITM with self signed certs though, dynamically generated or not.<br><br></div>Stuart<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse <span dir="ltr"><<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not a fan of dynamically generated self signed certificates - a recipe<br>
for leading users into shooting themselves in the foot.<br>
<br>
I say that after witnessing myself a user tricking themselves with their<br>
own man in the middle attack.<br>
<span class="HOEnZb"><font color="#888888"><br>
Darran.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 02/06/16 00:22, Stuart Douglas wrote:<br>
> Hi All,<br>
><br>
> I would like to propose that we add support for HTTP/2 out of the box in<br>
> Wildfly 10.1.<br>
><br>
> At the moment there are two main barriers to getting HTTP/2 two work:<br>
><br>
> - You need to set up a HTTPS connector, including generating keys etc.<br>
> For new users this is not as straightforward as it could be.<br>
> - You need to find the correct version of the Jetty ALPN jar and add it<br>
> to your boot class path. This is essentially a hack that modifies the<br>
> JDK SSL classes to allow them to support ALPN. A new version is needed<br>
> for every JDK8 release, so if you ever update the JVM HTTP/2 will stop<br>
> working (JDK9 has support for ALPN so this is not nessesary).<br>
><br>
> I am proposing that we do the following to address these issues:<br>
><br>
> - Add support for lazily generated self signed certificates, and include<br>
> this in the default config. This would mean that we would have a working<br>
> HTTPS connector in the default config, although the first request would<br>
> be a bit slow as it would need to generate a new self signed certificate<br>
> for localhost. This allows for SSL out of the box, without any impact on<br>
> startup time or any need for an installer to generate the certificate.<br>
><br>
> - I have dealt with the ALPN issue in Undertow using a reflection based<br>
> hack. I have created some code that parses and modifies the SSL<br>
> Server/Client hello messages to add/read APLN information, and I then<br>
> use reflection to update the HandshakeHash maintained by the engine so<br>
> the engines internal hash state used to generate the Finished frames<br>
> matches the data that was actually sent over the wire.<br>
><br>
> Yes I am aware that this is a massive hack, however I think it is<br>
> preferable to the current boot classpath hack, which has a lot of a<br>
> drawbacks. If this ever stops working at some point due to internal JDK<br>
> changes the boot classpath hack would still be usable, however I don't<br>
> think this is particularly likely, as the part of the JDK that this<br>
> modifies seems unlikely to change.<br>
><br>
> I think this would be a great usability feature, allowing developers to<br>
> get started with HTTPS and HTTP/2 straight away.<br>
><br>
> Thoughts?<br>
><br>
> Stuart<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
><br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>