[wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
Darran Lofthouse
darran.lofthouse at jboss.com
Wed Jun 8 08:36:21 EDT 2016
On 08/06/16 13:24, Jason T. Greene wrote:
>
>
>
>> 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.
We could even ship the CLI with a configured server trust store and add
the generated certificate to that store - it would not stop the prompt
from working but local CLI to local server the prompt would not even be
needed.
We need to think about how the Maven plug-in will resolve Elytron client
configuration as that is typically executed from within a build but with
a common security configuration on the way it may even be possible for
that to automatically use the local server generated trust store.
>
>>
>>>
>>> [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