Назад | Перейти на главную страницу

Как настроить транспорт КОНФИДЕНЦИАЛЬНО на HTTPD сервере Apache?

У нас был только один VirtualHost в конфигурации нашего сервера Apache 2.2:

<VirtualHost _default_:443>

Наши клиенты хотят иметь возможность вводить в браузер только имя сервера в HTTP (например, 10.10.0.1), и сервер будет автоматически перенаправлять на HTTPS. Итак, нам потребовалось добавить одно дополнение VirtualHost и настроить перенаправление на HTTP с помощью RewriteEngine:

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteCond %{REMOTE_HOST} !^127\.0\.0\.1.*$
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

Вопрос: Можно ли настроить транспорт КОНФИДЕНЦИАЛЬНО на HTTPD сервере Apache? Мы хотим найти конфигурацию, аналогичную следующей конфигурации web.xml:

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

Добавлено

Наше требование: мы хотим быть уверены на 100 процентов, что даже если мы открыли порт 80 для HTTP-соединения (которое допускает незашифрованное соединение), никакие данные не могут быть отправлены или получены с порта 80. В Java (см. Определение Java ниже), если настроен КОНФИДЕНЦИАЛЬНЫЙ а на сервере настроены как зашифрованные, так и не зашифрованные соединения (HTTP и HTTPS), используется только HTTPS.

Мы хотим найти аналогичный модуль конфигурации / Apache, который допускает аналогичную настройку.

Из http://docs.oracle.com/javaee/5/tutorial/doc/bnbxw.html: Укажите КОНФИДЕНЦИАЛЬНО, если приложение требует передачи данных, чтобы другие объекты не могли наблюдать за содержимым передачи.

Я не большой эксперт по Java, но, насколько я понимаю, КОНФИДЕНЦИАЛЬНАЯ гарантия на транспортировку означает, что данные будут зашифрованы во время передачи, чтобы никто другой не мог их прочитать.

Если это так, то, перенаправив всех на SSL (что в основном означает шифрование), вы уже это сделали.

Чтобы расширить приведенный выше ответ:

Конфигурация Apache принципиально отличается от конфигурации Java, поэтому вы не всегда можете перенести одну концепцию из другой. К сожалению, это один из тех случаев, когда концепция не совсем так хорошо транслируется. Apache не будет шифровать трафик на 80-м порту, если вы этого не сделаете, что было бы неприятно для браузеров. Что вы можете сделать, так это убедиться, что единственный трафик, который когда-либо происходит на порту 80, - это одно и только одно - все, к чему пользователь пытается получить доступ, должно быть выполнено перенаправлением на сайт SSL. Это означает, что apache не будет сервером ни страницы, ни скрипта, ни вообще никакого проксируемого трафика на порт 80 (за исключением того, что вы разрешаете незашифрованный трафик с localhost, что, как я полагаю, является преднамеренным).

Добавлю, что работаю в банке. Перенаправление порта 80 на порт 443 - это метод, который мы используем для принудительного шифрования трафика на некоторых наших сайтах. Это никогда не позволяло пропускать незашифрованный трафик.

Если вы хотите быть уверенным вдвойне, вы можете создать полностью отдельный каталог конфигурации apache, который прослушивает только порт 80, и установить его DocumentRoot на / var / www / notwanted /, который сам будет содержать только веб-страницу с перенаправление на него. Таким образом, вы будете держать эти две сущности более отдельными, с отдельными файлами журналов и т. Д. Я не думаю, что это необходимо с технической точки зрения, но это может упростить администрирование служб.

Rewrite Engine сверхмощный, но, вероятно, излишек для ваших нужд. Я бы просто использовал директиву Redirect, потому что ее проще понять и легче читать.

<VirtualHost *:80>
    Redirect 301 / https://www.whateverthewebsiteiscalled.com/
</VirtualHost>

Если вы действительно хотите использовать RewriteEngine, вам понадобится немного в конце, чтобы превратить его в перенаправление 301.

<VirtualHost *:80>
    RewriteEngine On
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

В любом случае, я не думаю, что вам нужно, чтобы RewriteConds добавлял что-нибудь полезное. Вход на порт 80 уже идентифицирует его как стандартный HTTP.