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 ;-)
[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
> <mailto:jason.greene@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 <mailto:stuart.w.douglas@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 <mailto:jason.greene@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 <mailto:stuart.w.douglas@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(a)gmail.com
<mailto:stuart.w.douglas@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
<mailto:jason.greene@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
>>> <mailto:stuart.w.douglas@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
>>>> <mailto:jason.greene@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
>>>> <mailto:stuart.w.douglas@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
>>>>> <mailto:jason.greene@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
>>>>>>
<mailto:stuart.w.douglas@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
>>>>>>
<mailto:jason.greene@redhat.com>> wrote:
>>>>>>
>>>>>>
>>>>>> > On Jun 2, 2016, at 11:29 AM,
Harold Campbell <hcamp(a)muerte.net
>>>>>>
<mailto:hcamp@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
>>>>>>
<mailto:wildfly-dev@lists.jboss.org>
>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>
_______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>> <mailto:wildfly-dev@lists.jboss.org>
>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev