[wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
Jason T. Greene
jason.greene at redhat.com
Tue Jun 7 07:47:59 EDT 2016
> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>
>
>
>> On 07/06/16 12:24, Jason T. Greene 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.
>
> In applications you configure which paths require a confidential
> transport guarantee so you can be selective.
>
> For managements all requests come over a single path so if you switch on
> SSL why not use it for the one and only path containing your sensitive
> requests.
Sure for standard web applications, but for anything using http upgrade that hits the root resource for all apps.
>
>> 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 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
>> 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