Hi,

On Fri, Dec 9, 2016 at 3:09 AM, David M. Lloyd <david.ll...@redhat.com> wrote:
> On 12/08/2016 07:34 PM, Bradford Wetmore wrote:
>>
>> Hi,
>>
>> Vinnie wrote:
>>>
>>> We understood when we examined these issues last year that the
>>> existing ALPN API would be sufficient. However it transpired,
>>> following HTTP2 server implementation efforts, that a particular
>>> use-case was difficult to address without sacrificing performance.
>>
>>
>> A few more details.
>>
>> The discussion/decisions we had last year ended with requiring servers
>> to inspect ClientHellos for the client's max TLS
>> protocol/ciphersuites/SNI/ALPNs/etc, and then do any necessary
>> configuration before actually starting the SSL/TLS/DTLS handshake on the
>> server side.  That included enabling specific SSL/TLS/DTLS protocols,
>> ordering the ciphersuites (calling
>> SSLParameters.setUseCipherSuitesOrder()) and ordering the ALPN values.
>> If it turned out that the resulting selected combination was incorrect,
>
>
> How could it turn out to be incorrect, when you know in advance what
> credentials you have, what cipher suites are available, and what protocols
> support which cipher suites?

If any logic you would run is different from JDK's, then the result
may be incorrect.
Say it another way, you run an old version of your code in a new JDK
version: the logic that was ok long time ago may not be the same years
later, and you get different results.

> I'm just curious because I'm pretty sure we
> haven't encountered this (I'll ask our web server folks to be sure though).

That would be helpful. Apart us (Jetty), nobody has actually
implemented ALPN using the new JDK9 API yet, as far as I know.

> Also I'd hate to see a worst-case situation where a this API was introduced
> (which is very reminiscent of ideas which were rejected for good reasons),
> and it turns out that in the end it's not quite sufficient after all,
> leaving a bit of dead code around.

>From how I understand this change, the whole mechanism of parsing the
ClientHello, running your logic, running again the ClientHello parsing
and the JDK logic, resulting in calling the application callbacks (for
SNI for example) twice, checking that both logics yielded the same
result, and if not take recovery actions, stays there, if you want to
go that way. You don't have to use the new code.

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

Reply via email to