On Jun 7, 2016, at 7:01 AM, Jason T. Greene
<jason.greene(a)redhat.com> wrote:
> 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.
(By pointing this out what I am getting at is that http json clients are distinct from
the console, I could technically want different policies for the two, although i do agree
that if TLs is available you tend to want it)
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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev