Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1

> On Jun 7, 2016, at 7:01 AM, Jason T. Greene <jason.greene(a)redhat.com&gt; wrote: > > > > >> On Jun 7, 2016, at 6:55 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: >> >> >> >>> On 07/06/16 12:47, Jason T. Greene wrote: >>> >>> >>>> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: >>>> >>>> >>>> >>>>> On 07/06/16 12:24, Jason T. Greene wrote: >>>>> Long term I think we want management using TLS, but that can of course >>>>> come in phases. Assuming 2) is one of those phases to come (either now >>>>> or later), a following step is that the CLI, and really any remoting >>>>> client, should prefer TLS with a defaulted trust store location that >>>>> points to the keystore. >>>>> >>>>> With 2) if we have the default of the attribute that forces redirect be >>>>> true, and our default config be false, then someone that carries over >>>>> their old config would not have a potential security weakness. If they >>>>> have a CLI script that adds the https port, it will fail, hopefully >>>>> sending a signal to look. Although, the user might just assume that oh >>>>> it's there, I don't have to do anything. >>>>> >>>>> Another interesting thing about 2 is that IIRC we have conflicting >>>>> behavior between the app port which doesn't force upgrade and the >>>>> management port which does. >>>> >>>> In applications you configure which paths require a confidential >>>> transport guarantee so you can be selective. >>>> >>>> For managements all requests come over a single path so if you switch on >>>> SSL why not use it for the one and only path containing your sensitive >>>> requests. >>> >>> Sure for standard web applications, but for anything using http upgrade that hits the root resource for all apps. >> >> But on the management port we still only have a single "app" using HTTP upgrade. > > Well technically you have two right. You have /console, and /management but sure they are always constant. (By pointing this out what I am getting at is that http json clients are distinct from the console, I could technically want different policies for the two, although i do agree that if TLs is available you tend to want it) > > I guess My point is just think it's weird that remote EJB (and other proprietary protocols over http upgrade) doesn't redirect and management does.

> > >> >>> >>>> >>>>> So my preference is 2, because at some point we have to do it anyway, >>>>> and if we have TLS out of the box might as well use it. >>>>> >>>>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com >>>>> <mailto:stuart.w.douglas@gmail.com>> wrote: >>>>> >>>>>> So while implementing this I have noticed a potential problem that it >>>>>> would be good to get some feedback on. >>>>>> >>>>>> If the management interface has SSL by default then the HTTP interface >>>>>> will always redirect to the HTTPS interface. This effectively breaks >>>>>> the management API, as clients such as the CLI, Arquillian etc will be >>>>>> redirected to HTTPS, and then reject the self signed certificate (as >>>>>> they should). >>>>>> >>>>>> I am not sure what to do about this, these are the options as I see them: >>>>>> >>>>>> 1) Don't enable SSL for the management interface (just for the >>>>>> Undertow subsystem). The management interface can still use this >>>>>> auto-generation capability, it just won't be enable by default (we >>>>>> could even leave the cert in the security domain, but just not enable >>>>>> the https interface). >>>>>> >>>>>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>>>>> controlled by an attribute). This will allow the CLI etc to work, but >>>>>> at the price of potentially reducing security, as some connections >>>>>> that would have previously been redirected to use HTTPS will no longer >>>>>> do this. >>>>>> >>>>>> 3) Enable it by default and leave it broken. We can setup some kind of >>>>>> automatic trust store thing so the local CLI works, and can get our >>>>>> test suite to work with Arquillian in a similar manner. Personally I >>>>>> think this is a terrible idea, but I am including it for completeness. >>>>>> >>>>>> Personally I think we should go for 1). Given that this is supposed to >>>>>> be about developer usability I don't think having management also use >>>>>> SSL as being that important. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>>>>> <jason.greene(a)redhat.com <mailto:jason.greene@redhat.com>> wrote: >>>>>> >>>>>> Awesome! Another idea I had on how we could get away with it being >>>>>> in server boot, is to have a pre-boot first time setup task, >>>>>> either launched from the shell/batch scripts or as a special >>>>>> pre-step before the AS module loads. We could then report boot >>>>>> time as the time AFTER first time installation tasks have >>>>>> completed, which I think is fair because the server hasn't yet >>>>>> been started. >>>>>> >>>>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>>>>> <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>> >>>>>> wrote: >>>>>> >>>>>>> I have some initial work on this at: >>>>>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>>>>> >>>>>>> If you go to https://localhost:9993 it will generate the >>>>>>> certificate (although all that will be served is a 404 page as >>>>>>> the console is not installed). >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>>>>> <stuart.w.douglas(a)gmail.com <mailto:stuart.w.douglas@gmail.com>> >>>>>>> wrote: >>>>>>> >>>>>>> I think that would actually end up being more complex. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>>>>> <jason.greene(a)redhat.com <mailto:jason.greene@redhat.com>> wrote: >>>>>>> >>>>>>> Another option could be a post boot task. So it's still >>>>>>> eager but don't block completed start. We'd still need to >>>>>>> block Tls ports though. So maybe this does not help >>>>>>> >>>>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>>>>> <stuart.w.douglas(a)gmail.com >>>>>>> <mailto:stuart.w.douglas@gmail.com>> wrote: >>>>>>> >>>>>>>> 2048 bits adds close to a second to first boot on my >>>>>>>> machine (obviously subsequent boots are unaffected). >>>>>>>> >>>>>>>> This is probably a bit much, I will work on getting a >>>>>>>> POC for the lazy loading approach implemented. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>>>>> <jason.greene(a)redhat.com >>>>>>>> <mailto:jason.greene@redhat.com>> wrote: >>>>>>>> >>>>>>>> We should really be generating 2048 bit keys. >>>>>>>> >>>>>>>> I don't like adding to our boot time, we have >>>>>>>> already seen it grow and this would be yet another case. >>>>>>>> >>>>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>>>>> <stuart.w.douglas(a)gmail.com >>>>>>>> <mailto:stuart.w.douglas@gmail.com>> wrote: >>>>>>>> >>>>>>>>> So I just did up a very quick prototype that >>>>>>>>> generates self signed certificates on startup and >>>>>>>>> it looks like the difference in startup time is >>>>>>>>> negligible (at least when generating 1024 bit RSA >>>>>>>>> keys). Even if the difference is measurable it only >>>>>>>>> affects the very first startup. >>>>>>>>> >>>>>>>>> I think that in order to simplify the >>>>>>>>> implementation of this it may be better to simply >>>>>>>>> generate the key of first startup, instead of >>>>>>>>> attempting to do it lazily. >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>>>>>> <jason.greene(a)redhat.com >>>>>>>>> <mailto:jason.greene@redhat.com>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> What will be default keysize? It has to be >>>>>>>>>> probably choosen to work also without >>>>>>>>>> "Java Cryptography Extension (JCE) >>>>>>>>>> Unlimited Strength Jurisdiction Policy" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Probably the largest that is supported without >>>>>>>>>> JCE. It does not matter that much, self signed >>>>>>>>>> certs are inherently insecure, this is a >>>>>>>>>> developer usability feature, not something >>>>>>>>>> that can be used in production. >>>>>>>>> >>>>>>>>> IIRC there is actually no limit on RSA key >>>>>>>>> size, it's only symmetric algs that are >>>>>>>>> limited, so we could use a standard 2048 bit >>>>>>>>> key without issue. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Stuart >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>>>>>> Douglas <stuart.w.douglas(a)gmail.com >>>>>>>>>> <mailto:stuart.w.douglas@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>> So I guess we should talk about how >>>>>>>>>> this should actually work. >>>>>>>>>> >>>>>>>>>> In terms of auto generating the key I >>>>>>>>>> was thinking we would need to add a >>>>>>>>>> new attribute to the 'keystore' >>>>>>>>>> element under the security realm, >>>>>>>>>> something like >>>>>>>>>> 'auto-generate-cert-host="localhost"'. >>>>>>>>>> I am not sure what other options we >>>>>>>>>> would need, or how configurable we >>>>>>>>>> should make it, but as this is for >>>>>>>>>> testing/development purposes I don't >>>>>>>>>> think we need to expose full control >>>>>>>>>> over the certificate generation process. >>>>>>>>>> >>>>>>>>>> In terms of the implementation we >>>>>>>>>> could just implement an SSLContext >>>>>>>>>> wrapper, that can do the generation >>>>>>>>>> and then create a 'real' SSLContext >>>>>>>>>> the first time it is asked to create >>>>>>>>>> and SSLEngine. >>>>>>>>>> >>>>>>>>>> Stuart >>>>>>>>>> >>>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>>>>>> Greene <jason.greene(a)redhat.com >>>>>>>>>> <mailto:jason.greene@redhat.com>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell <hcamp(a)muerte.net >>>>>>>>>>> <mailto:hcamp@muerte.net>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>>>> in Wildfly 10.1. >>>>>>>>>>> >>>>>>>>>>> This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>>>> 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>>>> bugs awaiting release. >>>>>>>>>>> >>>>>>>>>>> I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>>>> bug fixes be kept in mind. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Harold, >>>>>>>>>> >>>>>>>>>> That fix is already in master, so >>>>>>>>>> it will be included in 10.1. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jason T. Greene >>>>>>>>>> WildFly Lead / JBoss EAP Platform >>>>>>>>>> Architect >>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> wildfly-dev mailing list >>>>>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>>>>> <mailto:wildfly-dev@lists.jboss.org> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> wildfly-dev mailing list >>>>>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>>>>> <mailto:wildfly-dev@lists.jboss.org> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev