[wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
Jason T. Greene
jason.greene at redhat.com
Wed Jun 8 08:26:16 EDT 2016
> On Jun 8, 2016, at 5:24 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>
>> On 07/06/16 21:55, Stuart Douglas wrote:
>>
>>
>> On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene <jason.greene at redhat.com
>> <mailto: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.
>
> +1 It is a minimal config change then to use it.
Indeed, but we still need to have a script so the user doesn't have to dig around for the magic setting.
>
>
>>
>> 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 <mailto: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 <mailto: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 <mailto: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
>>>> <mailto: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
>>>>> <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
>>>>> <mailto: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
>>>>> <mailto: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
>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>>> <mailto: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
>>>>>>>> <mailto:jason.greene at redhat.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell <hcamp at muerte.net
>>>>>>>>> <mailto: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
>>>>>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> <mailto:wildfly-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org <mailto: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
>>
>>
>>
>>
>> _______________________________________________
>> 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
More information about the wildfly-dev
mailing list