On Jun 7, 2016, at 8:51 PM, Stuart Douglas
<stuart.w.douglas(a)gmail.com> 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.
It probably belongs in core so that other layered projects/products can get it as well.
However for 10.1 I think it's fine if we stick it in full for now.
Stuart
> On Wed, Jun 8, 2016 at 6:55 AM, Stuart Douglas <stuart.w.douglas(a)gmail.com>
wrote:
>
>
>> On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene <jason.greene(a)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(a)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(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
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)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