Clever Geek Handbook

JSE 1.8, Java Sandbox applet loaded over HTTPS but crossdomain.xml retrieved over HTTP

Hello to all Java / Applet gurus,

I stumbled upon an interesting issue with the latest JDK build (1.8.0_b26).

When launching the Sandbox Java applet with the latest JDK from Java code, we are trying to connect to the server using a different protocol - instead of the original HTTPS, we are using WSS (Secure Web Connections, we are using third party web applications). Java client library). As a result, the JVM tries to fetch the file crossdomain.xml

from the server. The problem is that the file is being retrieved using HTTP (not HTTPS).

For example, in our case, the server IP is 192.168.1.1, the applet is loaded via the default HTTPS port (443). Using trace level 5 in the Java Console, we can see what crossdomain.xml

is being pulled from http://192.168.1.1:443

. And of course it doesn't work because the server only listens for HTTPS connections on port 443 (not HTTP).

On the other hand, when we use the HTTP protocol and open a new WS (unsecured web connection) to the server, the problem does not arise because the crossdomain.xml is fetched from http://192.168.1.1:80

, and this is absolutely correct.

As we studied the problem further, we made a few comments:

  • You can provide an alternate file location crossdomain.xml

    using the jnlp.altCrossDomainXMLFiles

    Java VM option . We never managed to get this parameter to work for us (as in the java_arguments list, or as a single applet parameter). A possible reason might be that the parameter should only be used with the Webstart application (although it is not specifically written in the specs).

  • When establishing a connection with Websockets, the connection stack trace looks like this:

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.HttpEHTTPHeader (HttpClient.java:787) at sun.net.www.http.HttpClient.parseHTTP (HttpClient.java:647) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0 (HttpURLConnection.java:1534) 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 ) to sun.nio.ch.SocketChannelImpl.connect (SocketChannelImpl.java:624)

So, we looked at the latest public source code for the CrossDomainXML.java class (albeit from 2010). And it's obvious from the code that the http connection is always used when fetching a file crossdomain.xml

from the server, no matter what the browser's original connection is.

So the questions:

  • Could it be a JDK bug or strict HTTP usage crossdomain.xml

    by design?

  • Is jnlp.altCrossDomainXMLFiles

    JVM parameter supported inside Sandbox applet?

  • Is there a way to access the latest source code com.sun.deploy.net.CrossDomainXML.java

    to get a complete picture of what's going on?

Thank you in advance.

Regards, Mark

+3


source to share


2 answers


to get rid of the http: //myhost/crossdomain.xml request you can do nothing but add something like this to your java.policy file:

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


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

0


source


We use it like this in the applet at the start of the initialization 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();
}
0


source






More articles:


All Articles