[wildfly-dev] HTTP/2 out of the box in Wildfly 10.1
Darran Lofthouse
darran.lofthouse at jboss.com
Tue Jun 7 05:16:50 EDT 2016
I think #1 sounds better.
As a client the CLI in interactive mode works well when presented with
an untrusted certificate, problems will arise however with remote CLI,
Maven plug-in, jconsole / Remoting-JMX etc...
We can revisit the management clients later once we have migrated them
to a common security architecutre.
On 07/06/16 04:48, Stuart Douglas 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
>
More information about the wildfly-dev
mailing list