Смущает конфигурация SSL и Tomcat - PullRequest
Новая
       27

Смущает конфигурация SSL и Tomcat

1 голос
/ 25 июня 2010

Наше приложение работает в двух системах. Один использует https, а другой нет. Я пытаюсь настроить коннекторы Tomcat на работу, но когда я работаю в одной среде, она не работает в другой.

Мне сказали, что нам не нужно полностью «обрабатывать» SSL, поскольку это обрабатывается нашими балансировщиками нагрузки. Не уверен, что это значит.

Например: В одной структуре мы получим ошибки, запрещающие разрешение, а другая будет работать. Если мы изменим ситуацию вокруг, произойдет обратное, но вместо ошибок разрешения мы получим недействительную ошибку сертификата.

Документация tomcat по разъемам не очень хорошо описывает опции. Есть идеи, что мы делаем не так? 

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000"/>

<Connector port="443" protocol="HTTP/1.1" SSLEnabled="false" maxThreads="150" scheme="https" secure="false" clientAuth="false" sslProtocol="TLS"/>

Указанные выше коннекторы работают с каркасом http, но выдают «предупреждение о смешанном контенте» в IE, поскольку некоторые запросы - это http, а некоторые - https.

Любая помощь будет принята с благодарностью.

Ответы [ 2 ]

0 голосов
/ 25 июня 2010

Если вы находитесь за балансировщиком нагрузки, таким как Apache Httpd с mod_proxy (в обратном режиме), SSL-соединение будет между браузером и балансировщиком нагрузки (как сказал «erickson»). Вы действительно можете проверить login-config в своем файле web.xml (чтобы проверить, используете ли вы CLIENT-CERT).

Другая проблема, с которой вы можете столкнуться, это элемент transport-guarantee в web.xml: 

<security-constraint>
   <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>
</security-constraint>

Похоже, есть способ форсировать это с помощью специального клапана, если вы уверены, что вы надежно балансируете нагрузку. Вот статья на эту тему (перевод с французского) .

Наиболее вероятной причиной смешанного контента является загрузка изображений, которые не размещены на SSL. Вы можете обнаружить, что где-то в шаблоне есть логотип компании, жестко закодированный с помощью http://, или, возможно, некоторые заголовки Location возвращают URL http://. Последнее можно исправить с помощью такой конфигурации, как этот Apache Httpd (при условии, что это ваш балансировщик нагрузки), где вам нужно заменить его на правильный адрес, конечно: 

Header edit Location ^http://www.example.com/test/ https://www.example.com/test/

Многие сайты (даже от крупных компаний) смешивают контент. Это на самом деле плохо, потому что:

  • Пользователь не может точно знать, какие части страницы безопасны, а какие нет, не просматривая все запросы и, возможно, источник страницы.
  • Некоторые файлы cookie и информация просачиваются из HTTPS-запроса в простой HTTP-запрос. Если кто-то перехватит этот файл cookie по обычному HTTP, он может использовать его как HTTPS в качестве самозванца. (В частности, когда используются файлы cookie без флага безопасности.)
0 голосов
/ 25 июня 2010

Если у вас есть соединитель, прослушивающий порт 443, на нем должен быть включен SSL, потому что это порт HTTPS, и браузеры отправят сообщение SSL ClientHello, как только они подключатся - сервер не поймет этого, еслис поддержкой SSL.

Возможно, ваш балансировщик нагрузки прерывает SSL-соединения и пересылает запросы в Tomcat по обычному HTTP.В этом случае вам не нужен соединитель на порту 443.

Однако, похоже, что одно из ваших приложений может использовать клиентские сертификаты для выполнения аутентификации.Посмотрите элементы login-config в ваших файлах web.xml.Какие методы аутентификации используются?

Если вам требуются клиентские сертификаты, но SSL завершен на балансировщике нагрузки, аутентификация не может работать, потому что клиентский сертификат никогда не достигает Tomcat.

...