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

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




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