JSE 1.8, апплет Sandbox Java загружается через HTTPS, но файл crossdomain.xml извлекается с использованием HTTP

Привет всем гуру Java/Applet,

Я наткнулся на интересную проблему с последней сборкой JDK (1.8.0_b26).

При запуске Java-апплета Sandbox с последней версией JDK из кода Java мы пытаемся подключиться к серверу по другому протоколу — вместо исходного HTTPS мы используем WSS (защищенное соединение через веб-сокеты, мы используем стороннюю библиотеку Websockets Client Java). В результате JVM пытается получить crossdomain.xml файл с сервера. Проблема в том, что файл извлекается по протоколу HTTP (а не HTTPS).

Например, в нашем случае IP-адрес сервера — 192.168.1.1, апплет загружается через порт HTTPS по умолчанию (443). Используя уровень трассировки 5 в консоли Java, мы видим, что crossdomain.xml извлекается из http://192.168.1.1:443. И, конечно же, это не работает, потому что сервер прослушивает только соединения HTTPS через порт 443 (а не HTTP).

С другой стороны, когда мы используем HTTP-протокол и открываем новый WS (незащищенное подключение через веб-сокеты) к серверу, проблема не возникает, потому что crossdomain.xml извлекается из http://192.168.1.1:80, и это полностью правильно.

По мере дальнейшего изучения проблемы мы сделали еще несколько наблюдений:

  1. Можно указать альтернативное расположение файла crossdomain.xml с помощью параметра jnlp.altCrossDomainXMLFiles Java VM. Однако нам никогда не удавалось заставить этот параметр работать на нас (пробовали как в списке java_arguments, так и в качестве одиночного параметра апплета). Возможная причина может заключаться в том, что параметр следует использовать только с приложением Webstart (хотя это специально не прописано в спецификациях).

  2. При установлении соединения Websockets трассировка стека соединений выглядит следующим образом:

на sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:790) на sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) на sun.net.www.http.HttpClient.parseHTTPHeader (HttpClient.java:787) по адресу sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) по адресу sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534) по адресу sun. net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90) на sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1431) на sun.net.www.protocol. http.HttpURLConnection$9.run(HttpURLConnection.java:1429) в java.security.AccessController.doPrivileged(собственный метод) в java.security.AccessController.doPrivileged(AccessController.java:713) в sun.net.www.protocol.http .HttpURLConnection.getInputStream(HttpURLConnection.java:1428) на com.sun.deploy.net.CrossDomainXML.check(неизвестный источник) на com.sun.deploy.net.CrossDomainXML.check(неизвестный источник) на sun.plugin2. applet.SecurityManagerHelper.checkConnectHelper(неизвестный источник) в sun.plugin2.applet.AWTAppletSecurityManager.checkConnect(неизвестный источник) в sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:624)

Итак, мы рассмотрели последний общедоступный исходный код класса CrossDomainXML.java (правда, еще с 2010 года). И из кода видно, что при получении файла crossdomain.xml с сервера всегда используется http-соединение, независимо от исходного соединения браузера.

Итак, вопросы:

  1. Может быть, это ошибка JDK или строгое использование HTTP для crossdomain.xml предусмотрено дизайном?

  2. Поддерживается ли параметр jnlp.altCrossDomainXMLFiles JVM внутри апплета Sandbox?

  3. Есть ли способ получить доступ к последней версии исходного кода com.sun.deploy.net.CrossDomainXML.java, чтобы получить полную картину происходящего?

Заранее большое спасибо.

С уважением, Марк


applet java java-8 sandbox crossdomain.xml
person Mark V.    schedule 23.09.2014    source источник
comment
1.8.0_b26 далеко не «последняя сборка JDK». Между этой бета-версией и самой последней версией существует более одной версии выпуска. Последняя сборка JDK: jdk1.8.0_20 или jdk1.8.0_40_b06.   -  person Holger    schedule 23.09.2014
comment
@Holger, спасибо за быстрый ответ. Только что попробовал с jdk1.8.0_40_b06 - тот же результат. Также исследовал переменную jnlp.axlCrossDomainXMLFiles дальше. Кажется, он доступен для апплета Sandbox (без исключений безопасности), но я не нахожу способа заставить его работать.   -  person Mark V.    schedule 23.09.2014

Ответы (2)


arrow_upward
0
arrow_downward

чтобы избавиться от запроса http://myhost/crossdomain.xml, вы ничего не можете сделать, кроме добавив что-то подобное в ваш файл java.policy:

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

Вы можете ограничить это определенным лицом, подписывающим сертификат, чтобы применить эту политику, см. https://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html#SocketPermission

person Laurent Weislo    schedule 06.04.2015

arrow_upward
0
arrow_downward

Мы используем это как это в апплете в начале процесса инициализации (конструктор апплета), и это работает:

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();
}
person Frederic Leitenberger    schedule 30.05.2016