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

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



> On Jun 8, 2016, at 5:24 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
>> On 07/06/16 21:55, Stuart Douglas wrote:
>> 
>> 
>> On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene <jason.greene at redhat.com
>> <mailto:jason.greene at redhat.com>> 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.
>> 
>> 
>> We would leave the cert generation bit in the security realm, but just
>> don't enable the HTTPS interface. That way all that is required is for
>> the user to add the https="managements-https" attribute.
> 
> +1 It is a minimal config change then to use it.


Indeed, but we still need to have a script so the user doesn't have to dig around for the magic setting.

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