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

Jason T. Greene jason.greene at redhat.com
Wed Jun 8 08:24:44 EDT 2016




> On Jun 8, 2016, at 5:23 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> 
> 
>> On 07/06/16 21:51, Jason Greene 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.
>> 
>> 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]
> 
> That is not the JDK, that is the code I worked on to create a more 
> intuitive user experience when the CLI encounters an unexpected 
> certificate ;-)


Ah duh. Well that explains it. I misread the stack trace. This is exactly what I thought we should do for 11 as part of enabling this by default.

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