> 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.wetm...@oracle.com <mailto:bradford.wetm...@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.
