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

Как уже указывал Саймон (и вы догадываетесь о своем вопросе), это кажется невозможным напрямую с сервера. Поскольку запрос на 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-адрес, чтобы инициировать внешнюю перенаправление на другой сайт (который, естественно, потеряет статус ошибки). Даже если это «работает», я не уверен, что это обязательно будет хорошая идея. (?)

Извините, но насколько я знаю, это невозможно сделать, используя либо 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, которое следит за пакетами, а затем что-то делает с ним, кроме того, что я не могу спекулировать дальше или сказать вам полное решение.

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

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

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