In both cases users should be provided with the signatures before their
first attempt at connecting so they can verify they are genuine.
On 02/06/16 13:21, Jason T. Greene wrote:
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
> On Jun 2, 2016, at 6:04 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com>
> 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
> ----- Original Message -----
> From: "Stuart Douglas" <stuart.w.douglas(a)gmail.com>
> To: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
> Cc: wildfly-dev(a)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.
> On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse <darran.lofthouse(a)jboss.com
>> 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.
>>> 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.
>>> wildfly-dev mailing list
>> wildfly-dev mailing list
> wildfly-dev mailing list