I want to get server sockets working for HTTP/2 in Java, preferably TLS/https.
I've got a TLS server socket working fine, but browsers will only talk HTTP/1.1 to it. If I understand correctly, you need ALPN to get a HTTP/2 browser to connect to your TLS socket and start running HTTP/2 on it; browsers won't ask for upgrade to HTTP/2 on https. It seems Java8 does not do ALPN so far. Maybe there is some other way to coerce browsers to do HTTP/2, at least non-TLS.
So, anybody know how to make a Java server socket for HTTP/2?
Java won't get ALPN until at least JDK 9, which is slated for late 2016 or 2017.
Meanwhile, you can use Jetty's ALPN implementation, or better yet, use Jetty (or other servers as suggested) directly rather than doing your own HTTP/2 implementation using ServerSocket.
[Disclaimer, I am a Jetty committer]
Jetty 9.3 has great support for HTTP/2, including HTTP/2 Push.
FYI, Java Dev Team is preparing ALPN for Java 9.
Hopefully as you can see this issue, https://bugs.openjdk.java.net/browse/JDK-8062848,
ALPN support may be backported to JDK 8 so an implementation is needed
that does not introduce any new Java SE APIs. This may require
creating something in a com.oracle.ssl.net package or via System
Properties.
Related
I'm running a grpc server behind an AWS NLB. The NLB terminates SSL and the connection works from a go client. However a java/scala client connects with ALPN agent (at the moment I'm using conscrypt after failing with jetty), and it seems like at the end of the handshake the nlb does not return h2 as supported protocol which fails the negotiation. Is it just not supported in which case what is the alternative for akka grpc in java/scala with SSL? if it is supported what could the issue?
I'll post some code if it's the latter.
Thanks.
NLB does not support ALPN. See discussion of workaround/hack in: https://github.com/grpc/grpc-java/issues/5543.
Just launched - Network Load Balancer now supports TLS ALPN Policies
https://aws.amazon.com/about-aws/whats-new/2020/05/network-load-balancer-now-supports-tls-alpn-policies/
I'm trying to setup my springboot app on Debian Stretch production server. App uses TLS 1.2 and HTTP2 so I ran it with embedded Undertow and it worked flawlessly on Windows, however it seems to just drop connection after Client Hello on Linux.
this is what it looks like in wireshark:
I was able to connect over insecure http/1.1 with no problems though. I'm pretty sure it has something to do with TLS, because turning it off in application.properties allows Undertow to fallback to http/1.1. (I need multiplexing though)
And I can't find anything that could cause such behaviour. It's not keystore because I get no errors in Java.
The only thing I had to change from Windows were JVM parameters I had to change to make it use IPv4:
java -Xbootclasspath/p:/home/dptools/alpn-boot-8.1.11.v20170118.jar -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses -jar dpTools-0.0.1-SNAPSHOT.jar
Turns out it was keystore after all, not exactly keystore, but keypair inside. Apparently putting special characters in alias is not a good idea. after switching to alphanumeric alias it works. What concerns me is lack of any error on socket binding.
I want to make a large number of small HTTP requests from a client machine running Java 7 to an external web server over TLS and I would like to use session resumption to make this as efficient as possible.
The web server, however, only appears to support session resumption via the TLS session ticket extension, and so far, I have not seen any documented way of enabling this feature in the javax.net.ssl package.
Does the Java 7 TLS implementation support TLS session tickets on the client side? And if not, could anyone suggest a 3rd party library which does?
Many thanks
It looks as if this isn't even supported on Java 8 and has not been explicitly listed for Java 9.
I'm trying to communicate with a CUPS print-server that has "Encryption Required" set for all its connections. This means that, when you try to establish a connection to it, it asks to upgrade the connection to TLS-encrypted one, and neither Cups4j nor Jspi seem to be able to handle it.
Is there any way to connect to such a server from a Java application (using either these libraries or others)?
Your main problem is that CUPS/IPP is one of the rare protocols that use an HTTP to TLS upgrade, as described in RFC 2817. (https:// doesn't use that at all, see RFC 2818.) A consequence of that is that you'll find far less support in existing libraries for this upgrade.
In principle, upgrading a plain Socket into an SSLSocket isn't too difficult. However, since IPP relies on HTTP, it's likely that the libraries your library uses doesn't support this, since few HTTP libraries support RFC 2817.
I haven't looked at Cups4J, but Jspi clearly relies on Apache HTTP Client (probably version 3.x).
Support for RFC 2817 was discussed in 2011 on Apache HTTP Client mailing list, but it's not clear whether any of this made its way into the library. Anyway, the Jspi code is older than that, so it's fair to assume that it's not going to work.
A possible workaround:
Some IPP servers seem to support both TLS via an upgrade (RFC 2817) or via an initial connection (RFC 2818, the traditional https:// way). Perhaps yours does too. Check whether it listens to another port for TLS connections (e.g. by pointing an HTTPS client to it). (This could also be the same port if the server uses port unification.)
If this works, a quick patch to IppHttpConnection.java in Jspi should enable you to make it use https:// connections instead of http:// connections:
private static URI toHttpURI(URI uri) {
if (uri.getScheme().equals("ipp")) {
String uriString = uri.toString().replaceFirst("ipp", "http");
I'm not sure if ipps:// is standard, but you could use the same trick and replace ipps:// with https:// in the scheme. The rest should automatically be handled by the underlying HTTP library. (You might have to make sure your certificate is trusted too, but that's a different problem.)
I have to work on an old 1.3 JVM and I'm asked to create a secure connection to another server. Unfortunately the HttpsURLConnection only appears sinc JVM 1.4.
Is there another way to create a secure connection? Is there a library that I could you to add this fonctionnality?
You need to install the Java Secure Socket Extension (JSSE), which used to be required because Sun wouldn't ship it with the JDK because of comedy export restrictions. I had a look on Sun's web site, but the JDK 1.3 instructions are preving elusive. Bear in mind that JDK 1.3 is now end-of-lifed by Sun, so they may not have any information any more.
http://hc.apache.org/httpclient-3.x/sslguide.html
Check out the BouncyCastle implementation. It works all the way down to Java 1.1 and J2ME.
If JSSE doesn't work out for you (from #skaffman's answer, it may be hard to find documentation), you may want to look into some sort of a proxy. You could set up a daemon running on the same local machine (or trusted network), which then forwards the requests over HTTPS to the final end point. You could write this proxy server using a more modern JVM. Your legacy system would then point to the proxy rather than the real service.
Of course, if, by chance, you also have control over the final end point, you could perhaps just put both servers on a VPN.
You might be able to use JSSE.
skaffman links to the SSL guide for jakarta commons HttpClient. HttpClient is a good library for dealing with http.