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

[Stuart Douglas]

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 at 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 at 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 at 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 at 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 at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell <hcamp at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160606/27064bd2/attachment.html