[wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
Darran Lofthouse
darran.lofthouse at jboss.com
Wed Jun 8 06:28:45 EDT 2016
For schema changes I find it better to split out the forking of the
schema and then the configuration changes into separate commits - that
way we can actually see what changed which is essential when porting
upstream which will require changes to version 5 of the schema that
already exists. Is there any chance we can split this into two?
Darran.
On 08/06/16 02:51, Stuart Douglas wrote:
> I have created a PR for this here:
> https://github.com/wildfly/wildfly-core/pull/1596 (it will also require
> some upstream changes).
>
> Basically this just creates a new schema version, and add the
> 'generate-self-signed-certificate-host' attribute to the keystore.
>
> I have not added a script to enable HTTPS over management as Jason
> suggested, I am not 100% sure if that really belongs in core or as part
> of the full distribution.
>
> Stuart
>
> On Wed, Jun 8, 2016 at 6:55 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> 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.
>
> 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
>
More information about the wildfly-dev
mailing list