[wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
Darran Lofthouse
darran.lofthouse at jboss.com
Tue Jun 7 08:05:29 EDT 2016
On 07/06/16 13:03, Jason T. Greene wrote:
>
>
>
>> On Jun 7, 2016, at 7:01 AM, Jason T. Greene <jason.greene at redhat.com> wrote:
>>
>>
>>
>>
>>> On Jun 7, 2016, at 6:55 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>>>
>>>
>>>
>>>> On 07/06/16 12:47, Jason T. Greene wrote:
>>>>
>>>>
>>>>> 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.
>>>
>>> But on the management port we still only have a single "app" using HTTP upgrade.
>>
>> Well technically you have two right. You have /console, and /management but sure they are always constant.
>
> (By pointing this out what I am getting at is that http json clients are distinct from the console, I could technically want different policies for the two, although i do agree that if TLs is available you tend to want it)
>>
>> I guess My point is just think it's weird that remote EJB (and other proprietary protocols over http upgrade) doesn't redirect and management does.
In the management case those going for option #2 feels like say TLS is
good we should have TLS - but then we make it optional for all and down
to the individual client to decide if it wants to use it.
>>
>>
>>>
>>>>
>>>>>
>>>>>> 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
>>
>> _______________________________________________
>> 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