TLS extensions API, ALPN and HTTP 2.0

Michael McMahon michael.x.mcmahon at
Wed Sep 17 10:57:21 UTC 2014

Hi Simone,

I'm interested to understand why you think this Http 2 requirement
is difficult or impossible to implement in the JDK currently.

I thought, cipher suite selection would be independent of the ALPN 
So, a Http 2 client implementation would ensure that allowed ciphers
are in its list of proposed ciphers, and it's up to the server then to 
an allowed one. And presumably, a server implementation can do the same?

- Michael.

On 17/09/14 11:02, Simone Bordet wrote:
> Hi,
> On Tue, Sep 2, 2014 at 11:11 AM, Vincent Ryan <vincent.x.ryan at> wrote:
>> Your OCA is still being processed. When that has completed your name will be listed at:
>> Until then, we can discuss these TLS/HTTP issues but we cannot include your APIs or source code.
> Just an update on this...
> While ALPN should offer mechanism independent from the protocol
> advertised or the cipher used in the TLS connection, it seems that the
> HTTP/2.0 spec has put some constraint that link the protocol
> advertised to the ciphers negotiated
> (
> Currently it seems that this HTTP/2 requirement is difficult, if not
> impossible, to implement in the JDK.
> I am following the HTTP/2 expert group to see if this issue is
> resolved, and working on the Jetty code to implement this feature.
> The idea being to wait a bit to define the ALPN APIs until this issue
> is resolved, to see if the resolution requires changes in the ALPN
> APIs.
> Thanks !

More information about the security-dev mailing list