HTTP/2 out of the box in Wildfly 10.1

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Heiko W.Rupp
On 6 Jun 2016, at 0:59, Martin Choma wrote:

> I realized, that autogenerated JKS keystore probably won't work for
> Oracle/OpenJDK java in FIPS mode because of

I think this is actually a feature and helps not to abuse the
self-generation in production.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse
In reply to this post by Martin Choma
Lets no hijack Stuart's thread too much ;-)

But yes we will need to review what end users could be working with and
which certificate authorities they would want to interact with - the
tooling needs to be around how users will actually want to use it.

On 06/06/16 06:49, Martin Choma wrote:

> Hi Darran,
>
> talking about enhancing certificate obtaining process, i wonder if
> https://letsencrypt.org/ for automation could be utilized.
>
> On Fri, Jun 3, 2016 at 6:11 PM, Darran Lofthouse
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Enhancing TLS set up with features such as CSR generation and the
>     importing of the resulting signed certificates is something we are
>     working on.
>
>     Regards,
>     Darran Lofthouse.
>
>
>     On 03/06/16 15:28, Jorge Solórzano wrote:
>     > IMO this feature should be oriented to sysadmins not just developers. Is
>     > there really added value for developers to use HTTPS or HTTPS/2?
>     >
>     > It should be easy for sysadmins to setup TLS/SSL with "production"
>     > quality, from the gereration of the CSR that has to be send to the CA to
>     > the generation of the keystore.
>     >
>     > BTW... how is the performance of HTTPS using pure Java vs Apache for
>     > example? is this feature oriented for developers because for use in
>     > production is not recommended?
>     >
>     > *
>     > Ing. Jorge Solórzano*
>     > about.me/jorsol <http://about.me/jorsol>
>     >
>     <https://about.me/jorsol?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>
>     >
>     > On Fri, Jun 3, 2016 at 3:52 AM, Tomaž Cerar <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     This is completely off topic for this thread, there was one earlier
>     >     about what should go into 10.x....
>     >
>     >     Anywho, issue you mention was already resolved and hibernate updated
>     >     in master some time ago.
>     >     which means it will be in next release, whatever that release will be.
>     >
>     >     --
>     >     tomaz
>     >
>     >     On Thu, Jun 2, 2016 at 6:29 PM, Harold Campbell <[hidden email] <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>> 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.
>     >
>     >         --
>     >         Harold Campbell <[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >
>     >         Roses are red;
>     >                 Violets are blue.
>     >         I'm schizophrenic,
>     >                 And so am I.
>     >
>     >
>     >         _______________________________________________
>     >         wildfly-dev mailing list
>     >         [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     >
>     >
>     >     _______________________________________________
>     >     wildfly-dev mailing list
>     >     [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse
In reply to this post by Heiko W.Rupp
+1 An automatically generated self signed certificate should never be
usable on a FIPS installation out of the box.

On 06/06/16 12:27, Heiko W.Rupp wrote:

> On 6 Jun 2016, at 0:59, Martin Choma wrote:
>
>> I realized, that autogenerated JKS keystore probably won't work for
>> Oracle/OpenJDK java in FIPS mode because of
>
> I think this is actually a feature and helps not to abuse the
> self-generation in production.
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator
In reply to this post by Stuart Douglas
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 <[hidden email]> wrote:

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 <[hidden email]> wrote:
I think that would actually end up being more complex.

Stuart

On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Brian Stansberry
In reply to this post by Stuart Douglas
Darran,

Do you have any concerns about supporting an equivalent-or-better
variant of this in the Elytron subsystem for core 3.0 / WildFly 11?

AIUI the change Stuart describes below will become a "legacy" feature
once Elytron is in, so if people want to use Elytron (which we very much
want and it's our planned default) they'll want an equivalent feature.

I know you guys are planning to do stuff like this; I just want to
confirm it will be done for 11, since otherwise not having it will be a
barrier to people moving off the old stuff.

On 6/2/16 3:01 PM, Stuart Douglas 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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     > On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email] <mailto:[hidden email]>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Stuart Douglas
In reply to this post by jtgreene
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 <[hidden email]> 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 <[hidden email]> wrote:

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 <[hidden email]> wrote:
I think that would actually end up being more complex.

Stuart

On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev






_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse
I think #1 sounds better.

As a client the CLI in interactive mode works well when presented with
an untrusted certificate, problems will arise however with remote CLI,
Maven plug-in, jconsole / Remoting-JMX etc...

We can revisit the management clients later once we have migrated them
to a common security architecutre.

On 07/06/16 04:48, Stuart Douglas 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
> <[hidden email] <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>> 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
>>     <[hidden email] <mailto:[hidden email]>>
>>     wrote:
>>
>>         I think that would actually end up being more complex.
>>
>>         Stuart
>>
>>         On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene
>>         <[hidden email] <mailto:[hidden email]>> 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
>>             <[hidden email]
>>             <mailto:[hidden email]>> 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
>>>             <[hidden email]
>>>             <mailto:[hidden email]>> 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
>>>                 <[hidden email]
>>>                 <mailto:[hidden email]>> 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
>>>>                 <[hidden email]
>>>>                 <mailto:[hidden email]>> 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 <[hidden email]
>>>>>                         <mailto:[hidden email]>> 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 <[hidden email]
>>>>>                             <mailto:[hidden email]>> wrote:
>>>>>
>>>>>
>>>>>                                 > On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]
>>>>>                                 <mailto:[hidden email]>> 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
>>>>>                             [hidden email]
>>>>>                             <mailto:[hidden email]>
>>>>>                             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>                     _______________________________________________
>>>>>                     wildfly-dev mailing list
>>>>>                     [hidden email]
>>>>>                     <mailto:[hidden email]>
>>>>>                     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse
In reply to this post by Brian Stansberry
Will re-review that later - but the legacy code will still be usable in
WildFly 11.



On 06/06/16 22:28, Brian Stansberry wrote:

> Darran,
>
> Do you have any concerns about supporting an equivalent-or-better
> variant of this in the Elytron subsystem for core 3.0 / WildFly 11?
>
> AIUI the change Stuart describes below will become a "legacy" feature
> once Elytron is in, so if people want to use Elytron (which we very much
> want and it's our planned default) they'll want an equivalent feature.
>
> I know you guys are planning to do stuff like this; I just want to
> confirm it will be done for 11, since otherwise not having it will be a
> barrier to people moving off the old stuff.
>
> On 6/2/16 3:01 PM, Stuart Douglas 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 <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>
>>     > On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email] <mailto:[hidden email]>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse
In reply to this post by Darran Lofthouse
Just thinking if this is for out of the box development only purposes,
maybe this would be better with a short validity period supporting
localhost only.

That way they can get up and running quickly but still need to take
action to do it properly.  I think a long validity period with automatic
host name detection leaves more chance of this making it into production.


On 07/06/16 10:16, Darran Lofthouse wrote:

> I think #1 sounds better.
>
> As a client the CLI in interactive mode works well when presented with
> an untrusted certificate, problems will arise however with remote CLI,
> Maven plug-in, jconsole / Remoting-JMX etc...
>
> We can revisit the management clients later once we have migrated them
> to a common security architecutre.
>
> On 07/06/16 04:48, Stuart Douglas 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
>> <[hidden email] <mailto:[hidden email]>> 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
>>     <[hidden email] <mailto:[hidden email]>> 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
>>>     <[hidden email] <mailto:[hidden email]>>
>>>     wrote:
>>>
>>>         I think that would actually end up being more complex.
>>>
>>>         Stuart
>>>
>>>         On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene
>>>         <[hidden email] <mailto:[hidden email]>> 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
>>>             <[hidden email]
>>>             <mailto:[hidden email]>> 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
>>>>             <[hidden email]
>>>>             <mailto:[hidden email]>> 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
>>>>                 <[hidden email]
>>>>                 <mailto:[hidden email]>> 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
>>>>>                 <[hidden email]
>>>>>                 <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>                         <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>                             <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>
>>>>>>                                 > On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]
>>>>>>                                 <mailto:[hidden email]>> 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
>>>>>>                             [hidden email]
>>>>>>                             <mailto:[hidden email]>
>>>>>>                             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>                     _______________________________________________
>>>>>>                     wildfly-dev mailing list
>>>>>>                     [hidden email]
>>>>>>                     <mailto:[hidden email]>
>>>>>>                     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator
In reply to this post by Stuart Douglas
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

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 <[hidden email]> wrote:
I think that would actually end up being more complex.

Stuart

On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev






_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse


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.

> 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 <[hidden email]
> <mailto:[hidden email]>> 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
>> <[hidden email] <mailto:[hidden email]>> 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
>>     <[hidden email] <mailto:[hidden email]>>
>>     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
>>>     <[hidden email] <mailto:[hidden email]>>
>>>     wrote:
>>>
>>>         I think that would actually end up being more complex.
>>>
>>>         Stuart
>>>
>>>         On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene
>>>         <[hidden email] <mailto:[hidden email]>> 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
>>>             <[hidden email]
>>>             <mailto:[hidden email]>> 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
>>>>             <[hidden email]
>>>>             <mailto:[hidden email]>> 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
>>>>                 <[hidden email]
>>>>                 <mailto:[hidden email]>> 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
>>>>>                 <[hidden email]
>>>>>                 <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>                         <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>                             <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>
>>>>>>                                 > On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]
>>>>>>                                 <mailto:[hidden email]>> 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
>>>>>>                             [hidden email]
>>>>>>                             <mailto:[hidden email]>
>>>>>>                             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>                     _______________________________________________
>>>>>>                     wildfly-dev mailing list
>>>>>>                     [hidden email]
>>>>>>                     <mailto:[hidden email]>
>>>>>>                     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator


> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse <[hidden email]> 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.

>
>> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>> <[hidden email] <mailto:[hidden email]>> 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
>>>    <[hidden email] <mailto:[hidden email]>>
>>>    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
>>>>    <[hidden email] <mailto:[hidden email]>>
>>>>    wrote:
>>>>
>>>>        I think that would actually end up being more complex.
>>>>
>>>>        Stuart
>>>>
>>>>        On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene
>>>>        <[hidden email] <mailto:[hidden email]>> 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
>>>>            <[hidden email]
>>>>            <mailto:[hidden email]>> 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
>>>>>            <[hidden email]
>>>>>            <mailto:[hidden email]>> 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
>>>>>                <[hidden email]
>>>>>                <mailto:[hidden email]>> 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
>>>>>>                <[hidden email]
>>>>>>                <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>                        <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>                            <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]
>>>>>>>>                                <mailto:[hidden email]>> 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
>>>>>>>                            [hidden email]
>>>>>>>                            <mailto:[hidden email]>
>>>>>>>                            https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>                    _______________________________________________
>>>>>>>                    wildfly-dev mailing list
>>>>>>>                    [hidden email]
>>>>>>>                    <mailto:[hidden email]>
>>>>>>>                    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse


On 07/06/16 12:47, Jason T. Greene wrote:

>
>
>> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse <[hidden email]> 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.

>
>>
>>> 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 <[hidden email]
>>> <mailto:[hidden email]>> 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
>>>> <[hidden email] <mailto:[hidden email]>> 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
>>>>    <[hidden email] <mailto:[hidden email]>>
>>>>    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
>>>>>    <[hidden email] <mailto:[hidden email]>>
>>>>>    wrote:
>>>>>
>>>>>        I think that would actually end up being more complex.
>>>>>
>>>>>        Stuart
>>>>>
>>>>>        On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene
>>>>>        <[hidden email] <mailto:[hidden email]>> 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
>>>>>            <[hidden email]
>>>>>            <mailto:[hidden email]>> 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
>>>>>>            <[hidden email]
>>>>>>            <mailto:[hidden email]>> 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
>>>>>>                <[hidden email]
>>>>>>                <mailto:[hidden email]>> 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
>>>>>>>                <[hidden email]
>>>>>>>                <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>>                        <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>>                            <mailto:[hidden email]>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]
>>>>>>>>>                                <mailto:[hidden email]>> 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
>>>>>>>>                            [hidden email]
>>>>>>>>                            <mailto:[hidden email]>
>>>>>>>>                            https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>>                    _______________________________________________
>>>>>>>>                    wildfly-dev mailing list
>>>>>>>>                    [hidden email]
>>>>>>>>                    <mailto:[hidden email]>
>>>>>>>>                    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator



> On Jun 7, 2016, at 6:55 AM, Darran Lofthouse <[hidden email]> wrote:
>
>
>
>> On 07/06/16 12:47, Jason T. Greene wrote:
>>
>>
>>> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse <[hidden email]> 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 <[hidden email]
>>>> <mailto:[hidden email]>> 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
>>>>> <[hidden email] <mailto:[hidden email]>> 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
>>>>>   <[hidden email] <mailto:[hidden email]>>
>>>>>   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
>>>>>>   <[hidden email] <mailto:[hidden email]>>
>>>>>>   wrote:
>>>>>>
>>>>>>       I think that would actually end up being more complex.
>>>>>>
>>>>>>       Stuart
>>>>>>
>>>>>>       On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene
>>>>>>       <[hidden email] <mailto:[hidden email]>> 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
>>>>>>           <[hidden email]
>>>>>>           <mailto:[hidden email]>> 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
>>>>>>>           <[hidden email]
>>>>>>>           <mailto:[hidden email]>> 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
>>>>>>>               <[hidden email]
>>>>>>>               <mailto:[hidden email]>> 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
>>>>>>>>               <[hidden email]
>>>>>>>>               <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>>>                       <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>>>                           <mailto:[hidden email]>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]
>>>>>>>>>>                               <mailto:[hidden email]>> 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
>>>>>>>>>                           [hidden email]
>>>>>>>>>                           <mailto:[hidden email]>
>>>>>>>>>                           https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>
>>>>>>>>>                   _______________________________________________
>>>>>>>>>                   wildfly-dev mailing list
>>>>>>>>>                   [hidden email]
>>>>>>>>>                   <mailto:[hidden email]>
>>>>>>>>>                   https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator



> On Jun 7, 2016, at 7:01 AM, Jason T. Greene <[hidden email]> wrote:
>
>
>
>
>> On Jun 7, 2016, at 6:55 AM, Darran Lofthouse <[hidden email]> wrote:
>>
>>
>>
>>> On 07/06/16 12:47, Jason T. Greene wrote:
>>>
>>>
>>>> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse <[hidden email]> 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 <[hidden email]
>>>>> <mailto:[hidden email]>> 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
>>>>>> <[hidden email] <mailto:[hidden email]>> 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
>>>>>>  <[hidden email] <mailto:[hidden email]>>
>>>>>>  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
>>>>>>>  <[hidden email] <mailto:[hidden email]>>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>      I think that would actually end up being more complex.
>>>>>>>
>>>>>>>      Stuart
>>>>>>>
>>>>>>>      On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene
>>>>>>>      <[hidden email] <mailto:[hidden email]>> 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
>>>>>>>          <[hidden email]
>>>>>>>          <mailto:[hidden email]>> 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
>>>>>>>>          <[hidden email]
>>>>>>>>          <mailto:[hidden email]>> 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
>>>>>>>>              <[hidden email]
>>>>>>>>              <mailto:[hidden email]>> 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
>>>>>>>>>              <[hidden email]
>>>>>>>>>              <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>>>>                      <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>>>>                          <mailto:[hidden email]>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]
>>>>>>>>>>>                              <mailto:[hidden email]>> 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
>>>>>>>>>>                          [hidden email]
>>>>>>>>>>                          <mailto:[hidden email]>
>>>>>>>>>>                          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>
>>>>>>>>>>                  _______________________________________________
>>>>>>>>>>                  wildfly-dev mailing list
>>>>>>>>>>                  [hidden email]
>>>>>>>>>>                  <mailto:[hidden email]>
>>>>>>>>>>                  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse

On 07/06/16 13:03, Jason T. Greene wrote:

>
>
>
>> On Jun 7, 2016, at 7:01 AM, Jason T. Greene <[hidden email]> wrote:
>>
>>
>>
>>
>>> On Jun 7, 2016, at 6:55 AM, Darran Lofthouse <[hidden email]> wrote:
>>>
>>>
>>>
>>>> On 07/06/16 12:47, Jason T. Greene wrote:
>>>>
>>>>
>>>>> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse <[hidden email]> 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.

In the management case those going for option #2 feels like say TLS is
good we should have TLS - but then we make it optional for all and down
to the individual client to decide if it wants to use it.

>>
>>
>>>
>>>>
>>>>>
>>>>>> 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 <[hidden email]
>>>>>> <mailto:[hidden email]>> 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
>>>>>>> <[hidden email] <mailto:[hidden email]>> 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
>>>>>>>  <[hidden email] <mailto:[hidden email]>>
>>>>>>>  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
>>>>>>>>  <[hidden email] <mailto:[hidden email]>>
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>      I think that would actually end up being more complex.
>>>>>>>>
>>>>>>>>      Stuart
>>>>>>>>
>>>>>>>>      On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene
>>>>>>>>      <[hidden email] <mailto:[hidden email]>> 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
>>>>>>>>          <[hidden email]
>>>>>>>>          <mailto:[hidden email]>> 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
>>>>>>>>>          <[hidden email]
>>>>>>>>>          <mailto:[hidden email]>> 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
>>>>>>>>>              <[hidden email]
>>>>>>>>>              <mailto:[hidden email]>> 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
>>>>>>>>>>              <[hidden email]
>>>>>>>>>>              <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>>>>>                      <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>>>>>                          <mailto:[hidden email]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]
>>>>>>>>>>>>                              <mailto:[hidden email]>> 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
>>>>>>>>>>>                          [hidden email]
>>>>>>>>>>>                          <mailto:[hidden email]>
>>>>>>>>>>>                          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>>
>>>>>>>>>>>                  _______________________________________________
>>>>>>>>>>>                  wildfly-dev mailing list
>>>>>>>>>>>                  [hidden email]
>>>>>>>>>>>                  <mailto:[hidden email]>
>>>>>>>>>>>                  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

jtgreene
Administrator
In reply to this post by jtgreene
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]

[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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

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 <[hidden email]> wrote:
I think that would actually end up being more complex.

Stuart

On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________
wildfly-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Stuart Douglas


On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

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 <[hidden email]> wrote:
I think that would actually end up being more complex.

Stuart

On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________
wildfly-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Stuart Douglas
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.

Stuart

On Wed, Jun 8, 2016 at 6:55 AM, Stuart Douglas <[hidden email]> wrote:


On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

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 <[hidden email]> wrote:
I think that would actually end up being more complex.

Stuart

On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

> On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________
wildfly-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: HTTP/2 out of the box in Wildfly 10.1

Darran Lofthouse
In reply to this post by jtgreene


On 07/06/16 21:51, Jason Greene 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.
>
> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>> <[hidden email] <mailto:[hidden email]>> 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
>>> <[hidden email] <mailto:[hidden email]>> 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
>>>     <[hidden email] <mailto:[hidden email]>>
>>>     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
>>>>     <[hidden email] <mailto:[hidden email]>>
>>>>     wrote:
>>>>
>>>>         I think that would actually end up being more complex.
>>>>
>>>>         Stuart
>>>>
>>>>         On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene
>>>>         <[hidden email] <mailto:[hidden email]>>
>>>>         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
>>>>             <[hidden email]
>>>>             <mailto:[hidden email]>> 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
>>>>>             <[hidden email]
>>>>>             <mailto:[hidden email]>> 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
>>>>>                 <[hidden email]
>>>>>                 <mailto:[hidden email]>> 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
>>>>>>                 <[hidden email]
>>>>>>                 <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>                         <mailto:[hidden email]>> 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 <[hidden email]
>>>>>>>                             <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>                                 > On Jun 2, 2016, at 11:29 AM, Harold Campbell <[hidden email]
>>>>>>>                                 <mailto:[hidden email]>> 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
>>>>>>>                             [hidden email]
>>>>>>>                             <mailto:[hidden email]>
>>>>>>>                             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>>                     _______________________________________________
>>>>>>>                     wildfly-dev mailing list
>>>>>>>                     [hidden email]
>>>>>>>                     <mailto:[hidden email]>
>>>>>>>                     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email] <mailto:[hidden email]>
>> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1234