3

Hi all Java/Applet gurus,

I've stumbled upon an interesting problem with the latest JDK build (1.8.0_b26).

When running Sandbox Java Applet with the latest JDK, from within Java code we try to connect back to the server with a different protocol - instead of original HTTPS we use WSS (secured Websockets connection, we use third party Websockets Client Java library). As the result, JVM tries to retrieve crossdomain.xml file from the server. The problem is, that the file is retrieved using HTTP (and not HTTPS) protocol.

For example, in our case the server IP is 192.168.1.1, the applet is loaded over HTTPS default port (443). Using trace level 5 in Java console we see that the crossdomain.xml is retrieved from http://192.168.1.1:443. And of course it doesn't work because the server listens only for HTTPS connections on port 443 (and not HTTP).

On the other hand, when we use HTTP protocol and open new WS (unsecured Websockets connection) to the server, the problem doesn't appear, because crossdomain.xml is retrieved from http://192.168.1.1:80 and it is completely correct.

As the problem was further investigated, we've made few more observations:

  1. It is possible to provide alternative location of crossdomain.xml file using jnlp.altCrossDomainXMLFiles Java VM parameter. We've never succeed to make this parameter work for us though (tried both in java_arguments list and as lone applet parameter). The possible reason might be that the parameter should be used only with Webstart application (although it is not written specifically in specs).

  2. While establishing Websockets connection, the connection stack trace is as follows:

at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:790) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:787) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534) at sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90) at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1431) at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1429) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivileged(AccessController.java:713) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1428) at com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at sun.plugin2.applet.SecurityManagerHelper.checkConnectHelper(Unknown Source) at sun.plugin2.applet.AWTAppletSecurityManager.checkConnect(Unknown Source) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:624)

So we looked at the latest publicly available source code of CrossDomainXML.java class (back from 2010 though). And from the code it is evident, that http connection is always used while retrieving crossdomain.xml file from server, regardless what is the original browser connection.

So the questions are:

  1. Might it be a JDK bug or the strict usage of HTTP for crossdomain.xml is by design?

  2. Is jnlp.altCrossDomainXMLFiles JVM parameter supported inside Sandbox applet?

  3. Is there a way access the latest version of com.sun.deploy.net.CrossDomainXML.java source code to get a full picture of what is going on?

Thank you very much in advance.

Best regards, Mark

Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
Mark V.
  • 31
  • 3
  • `1.8.0_b26` is far from being the “latest JDK build”. There are more than one release versions between that beta and the most recent version. The latest JDK build is either [`jdk1.8.0_20`](http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html) or [`jdk1.8.0_40_b06`](https://jdk8.java.net/download.html). – Holger Sep 23 '14 at 10:11
  • @Holger, thank you for the fast response. Just tried with the `jdk1.8.0_40_b06` - same results. Also investigated `jnlp.axlCrossDomainXMLFiles` variable further. It seems to be accessible by Sandbox Applet (no security exception) but I don't find a way to make it work. – Mark V. Sep 23 '14 at 12:01

2 Answers2

0

in order to get rid of the http://myhost/crossdomain.xml request, there is nothing you can do except adding something like this into your java.policy file:

permission java.net.SocketPermission "myhost:1024-", "connect, resolve";

You can restrict that to a specific certificate signer in order to enforce this policy, see https://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html#SocketPermission

Laurent Weislo
  • 1
0

We use it like this in an applet early in the init-process (applet constructor) and it works:

try
{
    System.setProperty("jnlp.altCrossDomainXMLFiles", //
        "http://www.some-domain.de/crossdomain.xml" //
        + ",https://www.secure-domain.de:8443/crossdomain.xml" //
    );
}
catch (Exception e)
{
    e.printStackTrace();
}
Frederic Leitenberger
  • 1,949
  • 24
  • 32