Какое разрешение установить, чтобы избежать ошибки с Security-Manager с https-URLS?

Question

В программном обеспечении для клиента мы должны прочитать данные URL-адреса, чтобы проанализировать их содержание. Также клиент должен активировать Tomcat-Security-Manager, чтобы позволить Java-Policies управлять тем, что делает программа.

Теперь при чтении URL-адресов происходит исключение "javax.net.ssl.SSLKeyException: секретная ошибка администратора RSA", но только при определенных условиях:

• если URL-адрес HTTPS, но не для HTTP
• если Security-Manager активирован, а не когда он деактивирован или если в глобальном грант-блоке установлена ​​AllPermission
• только с Java 6, а не с Java 7 (клиенту требуется Java 6 в настоящее время)
• только с Tomcat6, а не с Tomcat 7 (клиенту требуется Tomcat 6 в настоящее время)

Нарушение безопасности происходит где-то в Java-коде, AllPermission, ограниченный нашей кодовой базой, не предотвращает ошибку.

Итак, есть ли у кого-то идея, какое разрешение установить для Java 6, чтобы он мог обрабатывать HTTPS?

Другая информация: Он работает внутри Tomcat, на Debian-Linux с OpenJDK.

РЕДАКТИРОВАТЬ: я добавил Java-Param "-Djava.security.debug=access,fail" в Tomcats /etc/default/tomcat6 в переменную JAVA_OPTS. Но в журналах у меня нет дополнительных сообщений. Возможно ли, чтобы код запрашивал разрешения перед их запуском?

РЕДАКТИРОВАТЬ 2: Я нашел правильное место и получил полную трассировку стека (удалены определенные части клиента):

javax.net.ssl.SSLKeyException: RSA premaster secret error

            at [...]
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:537)
            at java.lang.Thread.run(Thread.java:701)
    Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
            at javax.crypto.KeyGenerator.<init>(KeyGenerator.java:141)
            at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:191)
            ... 14 more

EDIT3: До сих пор я предполагал, что URL-адрес Java-класса был использован для доступа к содержимому ресурса. Но это неправда. Он использует из Grails-Code Groovy-URL-объект с помощью метода getText():

new URL(params.url).text

Ошибка происходит на этой линии. Это Grails-версия 2.2.4.

Answer 1

Решение после нескольких комментариев и ОП подтверждения решения (резюме)

Основной причиной является наличие sunjce_provider.jar в нескольких местах. Это было обнаружено ФП после того, как оно было предложено в качестве одной из многих возможных основных причин (см. Самый конец этого ответа и след комментария). Согласно комментарию ОП:

У меня есть sunjce_provider.jar в нескольких каталогах. Я попытался дать все три места для Java 6 прав, хотя, очевидно, только один - JAVA_HOME - и это сработало. Каким-то образом используется одно из других мест, хотя его нет в свойстве java.ext.dirs.

Поэтому в данном случае было решено, что приложение имеет права на доступ к правильной копии sunjce_provider.jar

Я оставил основные пункты из своего первоначального ответа и комментарии, которые помогли с диагнозом ниже для тех, кто находит это позже

Оригинальный ответ и комментарии, которые привели к решению

1. Это не произойдет с http потому что вашему веб-приложению (которое является клиентом для этого соединения, даже если оно запущено в tomcat) не нужно генерировать ключ в этой конфигурации.

2. Тот факт, что это происходит только тогда, когда SecurityManager включен, но не если он отключен или с глобальным AllPermission, указывает на ошибку разрешения файла. Это говорит о том, что это не проблема с длиной ключа (например, упомянутая здесь)

Другие подобные сообщения в Интернете указывают, что вероятной основной причиной является отсутствующий jar (обычно цитируется sunjce_provider.jar). Трассировка стека подтверждает, что первопричина NoSuchAlgorithmException где KeyGenerator ищет алгоритм SunTlsRsaPremasterSecret и не могу его найти. В вашем случае, так как это происходит только с определенным SecurityManager Конфигурация, это может быть недоступная банка (из-за разрешений безопасности).

Я думаю, что вы не включили grant codeBase права доступа к правильному каталогу, содержащему jar, необходимый для вашего алгоритма RSA keygen. Мой рекомендуемый порядок действий заключается в том, чтобы просмотреть ваше веб-приложение и структуру каталогов JRE, чтобы найти, где хранятся файлы времени выполнения, и убедиться, что у них есть разрешения. grant Эд в catalina.policy,

В конфигурации по умолчанию, например, вы должны увидеть где-нибудь

// These permissions apply to all shared system extensions
grant codeBase "file:${java.home}/jre/lib/ext/-" {
        permission java.security.AllPermission;
};

Подробнее о том, что это значит, см. В этом разделе менеджера безопасности Tomcat "Как". Вам нужно проверить несколько вещей - убедитесь, что ${java.home}/jre/lib/ext/ где ваши фляги выполнения. Если нет - измените путь, чтобы указать в нужном месте (именно там они находятся в моей версии OpenJDK 6 - сборка 27). В частности, вы должны увидеть sunjce_provider.jar а также sunpkcs11.jar там. Убедитесь, что указанный выше раздел существует в вашем файле политики.

Может случиться так, что код зависит от некоторых jar-файлов, которые находятся в вашем веб-приложении - например, в ${catalina.base}/path/to/your/webapp/WEB-INF/classes/ - в этом случае вам нужно предоставить разрешения для этого каталога.

---

Другие проблемы, которые вызывают такие же или похожие симптомы

1. Приложение не может найти или получить доступ sunpkcs11.jar выдаст то же сообщение об ошибке (проверено в системе Ubuntu+openjdk6+tomcat6). Вполне вероятно, что дубликаты этой банки тоже будут.

2. проверять /etc/java-6-openjdk/security/java.security, Там должен быть список поставщиков - проверьте, есть ли строка security.provider.n = sun.security.pkcs11.SunPKCS11 там - если эта строка отсутствует, вы также получите эту ошибку (проверено в той же системе)

3. В этом отчете об ошибках Debian говорится о проблемах с расположением jar-файлов при запуске под SecurityManager

---

Отладочный комментарий

Согласно другому ответу, вы можете попробовать добавить -Djava.security.debug=access,failure в CATALINA_OPTS или же JAVA_OPTS в вашем catalina.sh, чтобы включить отладку - которая должна войти в catalina.out по умолчанию (или там, где вы установили логирование через CATALINA_OUT в catalina.sh. Вы должны увидеть вывод SecurityManager там.

Вы также можете попробовать -Djava.security.debug=all. You will get a huge catalina.out`, но вы можете найти слова, которые могут помочь (например, "fail"!!!)

---

Следуйте коду из трассировки стека

Ваше исключение здесь брошено. Глядя на то, как это исключение может быть выдано - этот метод должен возвращать ноль. Глотает Exception s - что нехорошо и затрудняет точную диагностику того, какая часть этого кода дает сбой. Мои деньги были бы на этой линии - где canUseProvider() может вернуться false, Все это указывает на то, что банка поставщика по какой-то причине недоступна.

Я предполагаю, что вы не видели никаких нарушений доступа в выходных данных, даже с -Djava.security.debug=access,failure, Вы могли бы попробовать -Djava.security.debug=all, хотя это может просто привести к более неактуальным лесозаготовкам. Если нет нарушения прав доступа, у вас может быть две версии этого jar на вашем пути к классам, и среда выполнения обращается (или пытается получить доступ к неправильной). Случай, подобный этому, описан в этом Q / A.

Answer 2

Самый простой способ обнаружить все необходимые разрешения - запустить с аргументом.

-Djava.security.debug=access,failure

Затем вам будет предоставлена ​​полная информация о каждом отказавшем доступе к защите, о действующем домене защиты и т. Д.