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

Jason T. Greene jason.greene at redhat.com
Tue Jun 7 08:00:05 EDT 2016




> 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. 

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.


> 
>> 
>>> 
>>>> 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