Apache - по умолчанию настраивает https на настраиваемом порту

Я размещаю панель управления для веб-управления во втором экземпляре Apache, который выполняется на порту 2083. Он имеет порт 2082 для HTTP версии сайта, потому что ему нужно что-то запустить версию HTTP, но порт закрыт. Когда пользователь подключается к сайту следующим образом:

https://example.com:2083/

Они видят веб-панель. Однако, когда они посещают сайт следующим образом:

http://example.com:2083/

Они получают ошибку

Bad Request

Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.

Для продолжения нажмите ссылку. Вместо того, чтобы показывать эту ошибку, я хотел бы автоматически принудительно использовать протокол HTTPS по URL-адресу, чтобы использовать защищенную версию портала. Поскольку для этого SSL-порта на этой панели используется 2083, это вызывает конфликт, если они не указывают HTTPS. И использование файла .htaccess для добавления перенаправления не работает, поскольку порт загружен и видит ошибку до того, как она загрузит что-нибудь еще, заканчивая там без чтения файла .htaccess.

Я запускаю Apache 2.4.23 как на основной версии сайта (размещен на Windows-машине), так и на панели управления. Насколько мне известно, это новейшая доступная модель для модели модели win64.

Есть ли способ заставить HTTPS до того, как он загрузит что-нибудь еще?

Вот текущий файл httpd-ssl

Listen 2083
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
SSLProxyCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
SSLHonorCipherOrder on 
SSLProtocol all -SSLv2 -SSLv3
SSLProxyProtocol all -SSLv2 -SSLv3
SSLPassPhraseDialog  builtin
SSLSessionCache "shmcb:c:/panel/logs/ssl_scache(512000)"
SSLSessionCacheTimeout  300
<VirtualHost *:2083>
    SSLEngine on
    SSLCertificateFile "c:/panel/conf/ssl/sslcert.crt"
    SSLCertificateKeyFile "c:/panel/conf/ssl/sslcert.key"
    SSLCertificateChainFile "c:/panel/conf/ssl/sslcert.ca-bundle"
    ServerName https://sitename.com
    ServerAlias www.example.com
    DocumentRoot "c:/panel/htdocs/"
</VirtualHost>
5 голосов | спросил Kaboom 2 FebruaryEurope/MoscowbThu, 02 Feb 2017 17:20:09 +0300000000pmThu, 02 Feb 2017 17:20:09 +030017 2017, 17:20:09

3 ответа


4

Как уже указывал Саймон (и вы догадываетесь о своем вопросе), это кажется невозможным напрямую с сервера. Поскольку запрос на http://example.com:2083/ просто не может быть обработан сервером (когда он уже обрабатывает https://example.com:2083/). Как указывает ответ, это просто «плохой запрос».

Любое решение должно появиться на стороне клиента (или на каком-либо промежуточном устройстве), которое знает, что нужно «обновить» запрос, прежде чем отправлять запрос на ваш сервер. Есть расширения браузера, которые могут справиться с этим, но я подозреваю, что установка чего-то на клиенте нежелательна (или даже возможна).

Существует политика строгой транспортной безопасности (HSTS) , которая инструктирует клиента всегда запрашивайте HTTPS-версию сайта в последующих запросах. Однако в этом есть некоторые предостережения, которые я не вижу в этом случае:

  1. для этого требуется, чтобы пользователь уже успешно запросил версию HTTPS (после чего отправляется сообщение ответа Strict-Transport-Security, информирующее клиент, что все будущие запросы на этот хост должен быть HTTPS).

  2. HSTS используется, когда хост использует только SSL . Все запросы HTTP (без SSL) будут обновлены. HTTP больше не существует. Это означает, что http://domain.com:2082/ также не будет доступен. Браузер попытается обновить этот запрос до https://domain.com:2082/ (да, неверный порт - см. Ниже) - этот запрос теперь будет разорван.

  3. Как видно из вышеизложенного, HSTS действительно не работает с нестандартными портами (то есть с портами, отличными от 80/443). Для запрос не 80 портов, порт номер сохраняется в запросе . Таким образом, как указано выше, порт 2082 остается как порт 2082. (Поскольку намерение заключается в том, что все теперь HTTPS.)

( Кроме того: Я не изучал спецификацию, но мне интересно, почему желаемый порт не может быть установлен как часть начального Strict-Transport-Security, или у вас есть опция /флаг, который указывает браузеру направить запросы обратно на тот же порт, что и исходный «успешный» запрос? Казалось бы, это касается точек № 2 и № 3 выше?)

Итак, тот же вывод, что и Симон, кажется, невозможен.

Пользовательский 400 Bad Request ...?

Просто подумайте ... вы могли бы попытаться определить пользовательский 400 ErrorDocument, чтобы иметь более содержательное сообщение и, возможно, ссылку (или даже переадресация JavaScript?). Тем не менее, это нужно будет определить непосредственно в конфигурации основного сервера, чтобы иметь возможность запускаться. (Но в любом случае не всегда возможно переопределить некоторые системные ошибки Apache.) И я думаю, вам нужно будет указать абсолютный URL-адрес, чтобы инициировать внешнюю перенаправление на другой сайт (который, естественно, потеряет статус ошибки). Даже если это «работает», я не уверен, что это обязательно будет хорошая идея. (?)

ответил MrWhite 2 FebruaryEurope/MoscowbThu, 02 Feb 2017 19:09:12 +0300000000pmThu, 02 Feb 2017 19:09:12 +030017 2017, 19:09:12
6

Извините, но насколько я знаю, это невозможно сделать, используя либо htaccess, либо виртуальный хост Apache, так как для NON-SSL и SSL оба имеют собственный выделенный порт, они не могут использовать порт и его невозможно, чтобы браузер связывался с сервером с использованием неправильного протокола.

Большинство веб-сайтов будут использовать порты 80 и 443, эти порты не отображаются в адресной строке, поэтому, когда вы подключаетесь к http фактически подключаясь к http://example.com:80 и с сайтом с поддержкой SSL, который вы подключаетесь к https://example.com:443. Поэтому, когда вы видите перенаправление сайта с HTTP на HTTPS, это произошло через два порта, а не один.

У вас может быть:

  • http://example.com:80 перенаправить на https://example.com:443

У вас не может быть:

  • http://example.com:443 перенаправить на https://example.com:443

cPanel по умолчанию будет использовать эти порты:

2082    TCP CPanel default
2083    TCP CPanel default SSL

Основная проблема заключается в том, что браузер ожидает, что данные будут либо HTTPS, либо HTTP на основе адреса, введенного в панель действий, если не выполняется перенаправление, но затем браузер уведомляется об изменении протокола. Поскольку вы не можете подключиться к действию, которое перенаправляет браузер, не удастся. Я довольно уверен, что если бы был способ, то Apache или cPanel поддерживали бы его и документировали где-то.

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

ответил Simon Hayter 2 FebruaryEurope/MoscowbThu, 02 Feb 2017 18:01:24 +0300000000pmThu, 02 Feb 2017 18:01:24 +030017 2017, 18:01:24
5

Я не думаю, что вы можете сделать это прямо с Apache. Как только вы скажете, что вы используете SSL (или фактически TLS) на порту, он ожидает, что произойдет TLS-согласование, и все будет нарушено, если браузер отправит «обычный» HTTP, а не TLS.

Теоретически, должно быть возможно что-нибудь прослушать на этом порту, обнаружить из первых нескольких байтов, если это обычный HTTP или TLS, и действовать соответственно: если это HTTP, отправьте обратно перенаправление, иначе фактически запустите TLS (либо напрямую а затем проксировать /туннелировать содержимое открытого текста в Apache или просто перенести весь зашифрованный поток на Apache прозрачно).

Мне не было известно о том, что какое-либо программное обеспечение делает что-либо подобное из коробки, но кажется, что Nginx фактически поддерживает его, см. https://stackoverflow.com/a/15435799/3527940 для примера.

ответил jcaron 3 FebruaryEurope/MoscowbFri, 03 Feb 2017 02:19:27 +0300000000amFri, 03 Feb 2017 02:19:27 +030017 2017, 02:19:27

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132