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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold
Campbell <hcamp(a)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(a)lists.jboss.org
>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> wildfly-dev mailing list
>>>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev