Apache HTTPD/mod_proxy/Tomcat и SSL с авторизацией клиента

Question

Я уверен, что это FAQ, но я не мог найти ничего, что я считал тем же вопросом.

У меня есть несколько веб-приложений, работающих в Tomcat, с некоторыми страницами, например. страницу входа, защищенную SSL, как определено элементами конфиденциальности в их web.xmls. Одно из приложений также принимает аутентификацию клиента через сертификат. У меня также есть довольно обширная авторизационная авторизация на основе JAAS &, и между различными веб-приложениями есть все виды общего кода и различные конфигурации JAAS и т. Д.

Я действительно не хочу нарушать это, выполняя нижеследующее.

Я сейчас в процессе вставки Apache HTTPD с mod-proxy и mod-proxy-balancer перед Tomcat как балансировщик нагрузки, перед добавлением дополнительных экземпляров Tomcat.

То, что я хочу выполнить для HTTPS-запросов, заключается в том, что они перенаправлены «слепым» в Tomcat без HTTPD, являющегося конечной точкой SSL, то есть HTTPD просто передает зашифрованный текст непосредственно в Tomcat, чтобы TC мог продолжать делать то, что он уже делает с входами , SSL, гарантии конфиденциальности в web.xml и, самое главное, аутентификацию клиента.

Возможно ли это с описанной мной конфигурацией?

Я очень хорошо знаком с webapps и SSL и HTTPS и Tomcat, но мое знание внешних путей Apache HTTPD ограничено.

Днем, чтобы это перемещать, если необходимо, но это вроде программирования с конфигурационными файлами;)

Answer 1

Это звучит похоже на this question, где я ответил, что это невозможно:

Вы можете 'просто передайте трафик SSL/TLS на Tomcat из Apache. Либо ваше соединение SSL заканчивается на Apache, а затем вы должны отменить прокси трафик на Tomcat (SSL [между Httpd и Tomcat] редко бывает полезным в этом случае), или вы делаете , клиенты напрямую подключаются к Tomcat и позволяют обрабатывать соединение SSL .

Я признаю, что это немного меньше ссылок на эту заявку. Наверное, я ошибаюсь (я этого никогда не видел, но это не означает, что этого не существует ...).

Как вам известно, вам необходимо прямое соединение или полное соединение между пользовательским агентом и конечной точкой SSL (в этом случае вы хотите, чтобы это был Tomcat). Это означает, что Apache Httpd не сможет просмотреть URL-адрес: он будет знать имя хоста в лучшем случае (при использовании имени сервера).

Единственный вариант, который, кажется, не зависит от URL в mod_proxy documentation является AllowCONNECT, которая является то, что используется для вперед прокси-сервера для HTTPS.

Даже the options in mod_proxy_balancer ожидать путь в какой-то точке конфигурации. В его документации не упоминается протокол SSL/HTTPS («» Он обеспечивает поддержку балансировки нагрузки для протоколов HTTP, FTP и AJP13 »), тогда как mod_proxy говорит по крайней мере о SSL при упоминании CONNECT.

Я хотел бы предложить несколько вариантов:

• Использование iptables -На балансировки нагрузки, не проходя через HTTPd, заканчивая соединений в Tomcat непосредственно.

• Завершение соединения SSL/TLS на Httpd и использование простого обратного прокси HTTP для Tomcat.

Этот второй вариант требует немного большей конфигурации для обработки клиентских сертификатов и ограничений безопасности Tomcat.

Если вы настроили свой webapp с помощью <transport-guarantee>CONFIDENTIAL</transport-guarantee>, вам нужно будет сделать флаг Tomcat безопасным, несмотря на то, что он видит, что он исходит из своего простого HTTP-порта. Для Tomcat 5, here is an article (первоначально на французском языке, но автоматические переводы не так уж и плохо), описывая, как реализовать клапан для установки isSecure(). (Если вы не знакомы с valves, они похожи на фильтры, но работают в пределах Tomcat, прежде чем запрос будет передан в webapp. Их можно настроить в Catalina). Я думаю, что из Tomcat 5.5 HTTP connector secure option делает именно это, не требуя собственного клапана. Разъем AJP также имеет аналогичный вариант (если используется mod_proxy_ajp или mod_jk).

При использовании разъема AJP mod_proxy_ajp отправит первый сертификат в цепочку и сделает его доступным в Tomcat (через атрибут обычного запроса). Вам, вероятно, понадобится SSLOptions +ExportCertData +StdEnvVars. mod_jk (хотя и устарел, насколько я знаю) также может переслать всю цепочку, отправленную клиентом (используя JkOptions +ForwardSSLCertChain). Это может быть необходимо при использовании proxy certificates (что бессмысленно без цепи до их сертификата конечного объекта).

Если вы хотите использовать mod_proxy_http, трюк должен передать сертификат через an HTTP header (mod_header), используя что-то вроде RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s. Я не могу вспомнить точные детали, но важно убедиться, что этот заголовок очищен, так что он никогда не приходит из браузера клиента (кто может его подделать иначе). Если вам нужна полная цепь, вы можете попробовать this Httpd patch attempt. Для этого подхода, вероятно, потребуется дополнительный клапан/фильтр, чтобы включить заголовок в javax.servlet.request.X509Certificate (путем разбора блоков PEM).

несколько других моментов, которые могут быть интересны:

• Если я хорошо помню, что вам нужно, чтобы загрузить CRL файлы явным образом для HTTPd и configure it to use them. В зависимости от версии Httpd, которую вы используете, вам может потребоваться restart it to reload the CRLs.
• Если вы используете повторное согласование для получения вашего сертификата-клиента, директива CLIENT-CERT не сделает запрос Httpd сертификатом клиента, насколько я знаю (это делается иным образом через клапан, который может обращаться к SSLSession при использовании JSSE напрямую). Возможно, вам придется настроить соответствующий путь в Httpd для запроса сертификата клиента.