On Jun 7, 2016, at 6:55 AM, Darran Lofthouse
<darran.lofthouse(a)jboss.com> wrote:
> On 07/06/16 12:47, Jason T. Greene wrote:
>
>
>> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
>>
>>
>>
>>> On 07/06/16 12:24, Jason T. Greene 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.
>>
>> In applications you configure which paths require a confidential
>> transport guarantee so you can be selective.
>>
>> For managements all requests come over a single path so if you switch on
>> SSL why not use it for the one and only path containing your sensitive
>> requests.
>
> Sure for standard web applications, but for anything using http upgrade that hits the
root resource for all apps.
But on the management port we still only have a single "app" using HTTP
upgrade.
Well technically you have two right. You have /console, and /management but sure they are
always constant.
I guess My point is just think it's weird that remote EJB (and other proprietary
protocols over http upgrade) doesn't redirect and management 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 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
>>>
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