is it possible in openjdk 9 to advertise application protocol in the tls handshake?

[Bradford Wetmore]

 > So I think it is not working.

Thanks for letting us know, and providing a reproducible test case.  I 
have filed:

     JDK-8158978:  ALPN not working when values are set directly
                   on SSLServerSocket

and a code review will follow shortly.

BTW, your code didn't actually start the handshake, so 
getApplicationProtocol() won't return anything at that point.  But once 
the handshake has started, it would (should!).

Just FYI, another was to see the handshake message debug without using 
Wireshark is to use:

     java -Djavax.net.debug=all MyClass

Thanks again,

Brad


On 6/6/2016 9:45 PM, Jon Berg wrote:
> I have some basic TLS stuff running that seems OK, but I am not able to
> get ALPN working. I am using the binary version for linux
> (https://jdk9.java.net/download/).
>
> * Looking at wireshark, firefox sends in "Client Hello" with ALPN
> protocol h2,spdy/3.1,http/1.1
> * The "Server Hello" has no mention of anything related to ALPN. Also
> the code prints null. So I think it is not working.
> Here is a screen shot of wireshark: http://imgur.com/a/OX4kd
>
> Here is what I do in the code:
> Is this how it should be done?
>
> System.setProperty("jdk.tls.server.enableStatusRequestExtension", "true");
> sslContext = SSLContext.getInstance("TLS");
> sslContext.init(kmf.getKeyManagers(), null, null);
> SSLServerSocket sslserversocket = null;
>
> SSLServerSocketFactory sslserversocketfactory =
> sslContext.getServerSocketFactory();
> sslserversocket =
> (SSLServerSocket)sslserversocketfactory.createServerSocket(443);
>
>
> sslserversocket.setUseClientMode(false);
> sslserversocket.setWantClientAuth(false);
> String [] protocols = {"TLSv1","TLSv1.1","TLSv1.2"};
> sslserversocket.setEnabledProtocols(protocols);
>
> SSLParameters p = sslserversocket.getSSLParameters();
> p.setApplicationProtocols(new String[] {"http/1.1"});
> sslserversocket.setSSLParameters(p);
>
> String [] cipher = {"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
> "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
> "TLS_RSA_WITH_AES_128_GCM_SHA256",
> "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256",
> "TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
> "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"};
> sslserversocket.setEnabledCipherSuites(cipher);
>
> SSLSocket sslsocket = (SSLSocket)sslserversocket.accept();
> System.out.println(sslsocket.getHandshakeApplicationProtocol());
> //prints null
> System.out.println(sslsocket.getApplicationProtocol());
> //prints null
>
> Thanks,
>
>
> On Tue, Jun 7, 2016 at 1:52 AM, Bradford Wetmore
> <bradford.wetmore at oracle.com <mailto:bradford.wetmore at oracle.com>> wrote:
>
>     JEP 244/ALPN, aka JDK-8144083/JDK-8051498 went into JDK 9 late last
>     year.
>
>     The API/design is at:
>
>         https://bugs.openjdk.java.net/browse/JDK-8062848
>
>     In a nutshell, the client application sets the strings to send.  The
>     server application can parse the ClientHello if desired, and can do
>     any SSLSocket/SSLEngine preconfiguration before starting the
>     handshake. During handshaking, the server library code iterates its
>     set values, and compares with what was received (i.e.
>     server-preference) and chooses the first supported value.
>
>     While the API could support either ALPN or NPN, OpenJDK only has
>     ALPN support as NPN was on its way out at the time of the writing.
>
>     Brad
>
>
>
>
>
>
>     On 6/6/2016 3:10 PM, Jon Berg wrote:
>
>         Hi,
>
>         Given that you are acting as a server, it would be nice to be
>         able to offer
>         "http/1.1" as application.
>
>         The purpose of this is to get chrome to do tls false start which
>         require
>         that the server "advertise" http/1.1 in ALPN or NPN. In the tls
>         handshake.
>         To do this it is just and integer and that string that has to be
>         included
>         in the handshake message at the right place...
>
>         From looking at the api it seems that this is not supported.
>         And from reading http://openjdk.java.net/jeps/244 it sounds as
>         it does
>         not advertise anything, but for a server socket it is an
>         intersection of
>         what
>         the client sends and what the server is capable of.
>
>         Can you confirm that this is not supported in openjdk 9?
>
>         Thanks,
>         Jon Berg.
>
>