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

Sun Jun 26 21:32:23 EDT 2016

This is now in Wildfly upstream. The server will automatically generate a
self signed certificate and HTTP/2 is enabled by default.

Stuart

On Wed, Jun 8, 2016 at 10:28 PM, Jason T. Greene <jason.greene at redhat.com>
wrote:

>
>
> On Jun 7, 2016, at 8:51 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
> wrote:
>
> I have created a PR for this here:
> https://github.com/wildfly/wildfly-core/pull/1596 (it will also require
> some upstream changes).
>
> Basically this just creates a new schema version, and add the '
> generate-self-signed-certificate-host' attribute to the keystore.
>
> I have not added a script to enable HTTPS over management as Jason
> suggested, I am not 100% sure if that really belongs in core or as part of
> the full distribution.
>
>
> It probably belongs in core so that other layered projects/products can
> get it as well. However for 10.1 I think it's fine if we stick it in full
> for now.
>
>
>
>
> Stuart
>
> On Wed, Jun 8, 2016 at 6:55 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> > wrote:
>
>>
>>
>> On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene <jason.greene at redhat.com>
>> wrote:
>>
>>> So after reviewing this thread and discussing with a few folks, I’d like
>>> to propose, for 10.1:
>>>
>>> #1b - Same as the previous #1, we don’t enable TLS for management by
>>> default for now, but we additionally include an extra cli script to enable
>>> TLS.
>>>
>>
>> We would leave the cert generation bit in the security realm, but just
>> don't enable the HTTPS interface. That way all that is required is for the
>> user to add the https="managements-https" attribute.
>>
>> Stuart
>>
>>
>>>
>>> For 11 I think we should move to TLS by default, perhaps with a
>>> configurable URL policy on redirects, and address the incongruence with
>>> upgrade over app.
>>>
>>> I think its likely reasonable to redirect by default for 11, but we can
>>> hash that out further. One nice thing I had forgotten about is that the JDK
>>> will prompt for you to add unknown certs, and this all works with the
>>> CLI[1]. So it’s really only non-interactive clients we have to worry about,
>>> and that sounds like a reasonable burden for upgrade.
>>>
>>> [1]
>>>
>>> [disconnected /] connect
>>> Unable to connect due to unrecognised server certificate
>>> Subject    - CN=foo,OU=foo,L=Madison,ST=WI,C=US
>>> Issuer     - CN=myServer, OU=test, L=Madison, ST=WI, C=US
>>> Valid From - Tue Jun 07 15:22:06 CDT 2016
>>> Valid To   - Thu Jun 07 15:22:06 CDT 2018
>>> MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d
>>> SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b
>>>
>>> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t
>>>
>>>
>>>
>>> On Jun 7, 2016, at 6:24 AM, Jason T. Greene <jason.greene at redhat.com>
>>> wrote:
>>>
>>> Long term I think we want management using TLS, but that can of course
>>> come in phases. Assuming 2) is one of those phases to come (either now or
>>> later), a following step is that the CLI, and really any remoting client,
>>> should prefer TLS with a defaulted trust store location that points to the
>>> keystore.
>>>
>>> With 2) if we have the default of the attribute that forces redirect be
>>> true, and our default config be false, then someone that carries over their
>>> old config would not have a potential security weakness. If they have a CLI
>>> script that adds the https port, it will fail, hopefully sending a signal
>>> to look. Although, the user might just assume that oh it's there, I don't
>>> have to do anything.
>>>
>>> Another interesting thing about 2 is that IIRC we have conflicting
>>> behavior between the app port which doesn't force upgrade and the
>>> management port which does.
>>>
>>> So my preference is 2, because at some point we have to do it anyway,
>>> and if we have TLS out of the box might as well use it.
>>>
>>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
>>> wrote:
>>>
>>> So while implementing this I have noticed a potential problem that it
>>> would be good to get some feedback on.
>>>
>>> If the management interface has SSL by default then the HTTP interface
>>> will always redirect to the HTTPS interface. This effectively breaks the
>>> management API, as clients such as the CLI, Arquillian etc will be
>>> redirected to HTTPS, and then reject the self signed certificate (as they
>>> should).
>>>
>>> I am not sure what to do about this, these are the options as I see them:
>>>
>>> 1) Don't enable SSL for the management interface (just for the Undertow
>>> subsystem). The management interface can still use this auto-generation
>>> capability, it just won't be enable by default (we could even leave the
>>> cert in the security domain, but just not enable the https interface).
>>>
>>> 2) Disable automatic redirects for HTTP upgrade requests (potentially
>>> controlled by an attribute). This will allow the CLI etc to work, but at
>>> the price of potentially reducing security, as some connections that would
>>> have previously been redirected to use HTTPS will no longer do this.
>>>
>>> 3) Enable it by default and leave it broken. We can setup some kind of
>>> automatic trust store thing so the local CLI works, and can get our test
>>> suite to work with Arquillian in a similar manner. Personally I think this
>>> is a terrible idea, but I am including it for completeness.
>>>
>>> Personally I think we should go for 1). Given that this is supposed to
>>> be about developer usability I don't think having management also use SSL
>>> as being that important.
>>>
>>> Stuart
>>>
>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene <
>>> jason.greene at redhat.com> wrote:
>>>
>>>> Awesome! Another idea I had on how we could get away with it being in
>>>> server boot, is to have a pre-boot first time setup task, either launched
>>>> from the shell/batch scripts or as a special pre-step before the AS module
>>>> loads. We could then report boot time as the time AFTER first time
>>>> installation tasks have completed, which I think is fair because the server
>>>> hasn't yet been started.
>>>>
>>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
>>>> wrote:
>>>>
>>>> I have some initial work on this at:
>>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576
>>>>
>>>> If you go to https://localhost:9993 it will generate the certificate
>>>> (although all that will be served is a 404 page as the console is not
>>>> installed).
>>>>
>>>> Stuart
>>>>
>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas <
>>>> stuart.w.douglas at gmail.com> wrote:
>>>>
>>>>> I think that would actually end up being more complex.
>>>>>
>>>>> Stuart
>>>>>
>>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <
>>>>> jason.greene at redhat.com> wrote:
>>>>>
>>>>>> Another option could be a post boot task. So it's still eager but
>>>>>> don't block completed start. We'd still need to block Tls ports though. So
>>>>>> maybe this does not help
>>>>>>
>>>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas <
>>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>>
>>>>>> 2048 bits adds close to a second to first boot on my machine
>>>>>> (obviously subsequent boots are unaffected).
>>>>>>
>>>>>> This is probably a bit much, I will work on getting a POC for the
>>>>>> lazy loading approach implemented.
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene <
>>>>>> jason.greene at redhat.com> wrote:
>>>>>>
>>>>>>> We should really be generating 2048 bit keys.
>>>>>>>
>>>>>>> I don't like adding to our boot time, we have already seen it grow
>>>>>>> and this would be yet another case.
>>>>>>>
>>>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas <
>>>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>>>
>>>>>>> So I just did up a very quick prototype that generates self signed
>>>>>>> certificates on startup and it looks like the difference in startup time is
>>>>>>> negligible (at least when generating 1024 bit RSA keys). Even if the
>>>>>>> difference is measurable it only affects the very first startup.
>>>>>>>
>>>>>>> I think that in order to simplify the implementation of this it may
>>>>>>> be better to simply generate the key of first startup, instead of
>>>>>>> attempting to do it lazily.
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene <
>>>>>>> jason.greene at redhat.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> What will be default keysize? It has to be probably choosen to work
>>>>>>>>> also without "Java Cryptography Extension (JCE) Unlimited Strength
>>>>>>>>> Jurisdiction Policy"
>>>>>>>>>
>>>>>>>>
>>>>>>>> Probably the largest that is supported without JCE. It does not
>>>>>>>> matter that much, self signed certs are inherently insecure, this is a
>>>>>>>> developer usability feature, not something that can be used in production.
>>>>>>>>
>>>>>>>>
>>>>>>>> IIRC there is actually no limit on RSA key size, it's only
>>>>>>>> symmetric algs that are limited, so we could use a standard 2048 bit key
>>>>>>>> without issue.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Stuart
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas <
>>>>>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> So I guess we should talk about how this should actually work.
>>>>>>>>>>
>>>>>>>>>> In terms of auto generating the key I was thinking we would need
>>>>>>>>>> to add a new attribute to the 'keystore' element under the security realm,
>>>>>>>>>> something like 'auto-generate-cert-host="localhost"'. I am not sure what
>>>>>>>>>> other options we would need, or how configurable we should make it, but as
>>>>>>>>>> this is for testing/development purposes I don't think we need to expose
>>>>>>>>>> full control over the certificate generation process.
>>>>>>>>>>
>>>>>>>>>> In terms of the implementation we could just implement an
>>>>>>>>>> SSLContext wrapper, that can do the generation and then create a 'real'
>>>>>>>>>> SSLContext the first time it is asked to create and SSLEngine.
>>>>>>>>>>
>>>>>>>>>> Stuart
>>>>>>>>>>
>>>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <
>>>>>>>>>> jason.greene at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell <hcamp at muerte.net>
>>>>>>>>>>> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, 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.
>>>>>>>>>>> >>
>>>>>>>>>>> >
>>>>>>>>>>> > This lowly user desperately wants a release containing the fix
>>>>>>>>>>> to WFLY-
>>>>>>>>>>> > 6283 sooner rather than later. I'm sure other people have
>>>>>>>>>>> other pet
>>>>>>>>>>> > bugs awaiting release.
>>>>>>>>>>> >
>>>>>>>>>>> > I have no opinion on HTTP/2 being added other than to ask that
>>>>>>>>>>> pent up
>>>>>>>>>>> > bug fixes be kept in mind.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi Harold,
>>>>>>>>>>>
>>>>>>>>>>> That fix is already in master, so it will be included in 10.1.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Jason T. Greene
>>>>>>>>>>> WildFly Lead / JBoss EAP Platform Architect
>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>
>>>
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160627/55480ee9/attachment-0001.html 