Apache: незахищений запит, надісланий до захищеного порту ... хочу переспрямувати

Передмова

По-перше: Просто Порт 80 -> Порт 443 Перепишіть НЕ виправить це. Майже в кожному попередньому запитанні, поштовій нитці, потоці форуму тощо, я виявив, що це була перша невігласна відповідь, і її кілька разів папугували.

По-друге: Так, я знаю, що ви не можете обслуговувати трафік HTTP та HTTPS на одному порті. Це не те.

Сценарій:

Apache Server розміщує декілька сайтів через множення портів. Порт 80 обслуговує загальнодоступний сайт. Порт 443 обслуговує захищену версію цього сайту.

Порти 7443, 8443 та 9443 обслуговують окремі сайти, захищені SSL.

Якщо користувач вводить неправильну URL-адресу або надається недійсне посилання, скажімо http: //hostname.tld: 7443 , їм надається така смішна сторінка:

Повідомлення про помилку Apache Bad Request

Замість сервера просто перенаправляйте їх на https: //hostname.tld: 7443 .

Моє запитання полягає в тому, як ви можете змінити поведінку Apache або це повідомлення про помилку, щоб в імені бабки Зевса змінити поведінку Apache або автоматично перенаправити користувача?

Apache, очевидно, обслуговує не https-запит (для відображення цього повідомлення про помилку), навіть якщо він налаштований для HTTPS. Мені здається надзвичайно німим не просто робити переадресацію за замовчуванням, але я можу зрозуміти, чому вони пішли з поведінкою, яку вони робили, навіть якщо я з цим не згоден. Отже, моє запитання: чи можете ви це змінити? Вони обробляють помилку ДЕЙШЕ, і якщо Apache є рогом конфігурації, що це таке, очевидно, існує десь директива, де можна поводитися з цією поведінкою, але я не зміг її знайти за кілька годин майстерності до цих пір.

Оновлення:

Я спробував різні речі, зокрема:

використовуючи ErrorDocument 400директиви, щоб дістатися до CGI та PHP-скрипту, які просто надсилають Status 301та Locationзаголовки. Це призводить до появи порожньої сторінки. Використання ErrorDocument 400 https://hostname.tld:7443просто призводить до того, що посилання відображається на сторінці.
Використовуючи майже будь-яку комбінацію mod_rewriteя або Google, можна придумати, включаючи бланкетні заяви, які повністю спрямовують сайт; вони ніколи не працюють. Буквально вони нічого не роблять. Я гадаю, що Apache натискає на вказану вище помилку, перш ніж намагатися обробити директиви перезапису.

Я не можу використовувати перенаправлення на основі портів через користувацькі порти. Я не можу використовувати переадресації на основі скриптів, оскільки вони ніколи не отримуються через невідповідність http / https. Я майже готовий пояснити це помилкою або ненавмисною поведінкою, але хтось мав намір покласти там дуже звичайне повідомлення про помилку, вони не турбувались, думаючи, що, можливо, ви хочете просто покататися на URL-адресу, яку вони вже надають ?

— шкірка
джерело

Дивіться прийняту відповідь як

— Daniel Vérité

Даніель, це було одне із багатьох питань, які я знайшов, і вирішення яких я намагався перед тим, як поставити це питання. Я думаю, що проблема полягала в компоненті PHP, але оскільки оновлення відповіді @ hrunting на даний момент працює для мене прекрасно, я більше не збираюся занурюватися в неї, ніж у мене вже є; принаймні, поки не доведеться.

— peelman

Резюме пов'язаного відео, воно ідеально передає мої емоції

— michele b

Відповіді:

Я думаю, що це, мабуть, помилка в тому, як Apache 2.2 і нижче справляються з цією конкретною обставиною.

Схоже, що при 400 Bad Requestпомилці читання SSL Apache 2.2 не повертає код відповіді HTTP або заголовки, лише тіло відповіді HTTP. Я тестую теллетнею до порту 443 і надсилаю:

GET / HTTP/1.1

Сервер негайно повертає (для мене):

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://server.tld/"><b>https://server.tld/</b></a></blockquote></p>
</body></html>

Зверніть увагу на відсутність коду відповіді HTTP або будь-яких заголовків HTTP.

Коли я роблю це на сервері Apache 2.4, я отримую:

HTTP/1.1 400 Bad Request
Date: Sun, 10 Feb 2013 00:47:23 GMT
Server: Apache/2.4.3 (Unix) OpenSSL/1.0.0g
Content-Length: 462
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
</p>
<hr>
<address>Apache/2.4.3 (Unix) OpenSSL/1.0.0g Server at server.tld Port 443</address>
</body></html>

Якщо я встановив рядок ErrorDocument, як і ви:

ErrorDocument 400 https://server.tld/

Тоді я отримую HTML-код для переадресації 302, але знову ж таки, жоден із заголовків. Без коду відповіді на переадресацію 302 та Location:заголовка браузер не буде перенаправляти.

Спробуйте оновити Apache 2.4 і побачити, чи працює він. Я протестував і підтвердив, щонайменше, Apache 2.4.3, але я не пережив зусиль, щоб точно знайти, коли ця поведінка була оновлена. Я підозрюю, що за велику кількість робіт, які вони провели, підготувавши 2.4, вони виправили небажану поведінку як побічний ефект.

Відповідні помилки Apache httpd:

44907
50823

ОНОВЛЕННЯ

Ви можете змусити помилку Apache дати вам потрібну поведінку (переспрямування), за допомогою сценарію роздрукувати його заголовки (які не будуть надіслані клієнту), а потім вручну роздрукувати знову потрібні заголовки. Ось базовий сценарій Perl, який працює під Apache 2.2.22:

#!/usr/bin/perl

use strict;
use CGI;

my $q = CGI->new();

# this will cause Apache to handle the response properly, but is meaningless otherwise
print $q->redirect("https://localhost/");

# this actually performs the redirect
print "HTTP/1.1 302 Found\r\n";
print "Location: https://localhost/\r\n";
print "\r\n";

# you can do whatever you want here; this will be the HTML body

Вам слід пам’ятати, що існують й інші причини, за допомогою яких 400 може бути створено, крім простого спілкування з портом SSL без SSL. Найпростіший спосіб визначити це - шукати HTTPSзмінну середовища. Якщо він встановлений, то SSL було узгоджено належним чином, і щось інше спричиняє 400 (не робіть трюк з подвійним заголовком, якщо це так). Якщо HTTPSне встановлено, поверніть переспрямування, як зазначено вище.

— шурхіт
джерело

Святий. Лайно. Ідеальний відповідь. Грацій.

— пільман

Ви знаєте, коли я читаю це, я думаю собі: "Людина, це справді гарно, якщо ти маєш Apache 2.2 і ти хочеш такого виду перенаправлення". Я не збираюся намагатися знайти відповідний дебют Apache 2.4 (або зробити свій власний) для моєї системи Ubuntu. Надіваюся, ви можете зламати рішення зі свого сценарію PHP. Apache явно просто скидає вихід на клієнта, тому якщо ви повернете конкретний очікуваний контент, я думаю, ви можете отримати поведінку, яку ви шукаєте, не оновлюючи Apache. Спробуйте, щоб ваш сценарій PHP роздрукував "HTTP / 1.1 302 Знайдено \ r \ nLocation: server.tld \ r \ n \ r \ n".

— hrunting

Проблема в тому, що не видається, що сценарій PHP обробляється. Слід зазначити, що це зараз сидить на Apache 2.2.22 на Ubuntu Server 12.04. І так, це справді, справді смокче; особливо якщо ви зауважуєте, що в цих звітах про помилки вони, здається, повністю налаштовані проти навіть надання можливості просто зробити автоматичне переадресацію, і, мабуть, немає великої надії, що 2.2 коли-небудь отримає виправлення.

— пільман

І як я вже говорив вище, мені просто немає сенсу, чому ви переживаєте проблему, щоб написати це повідомлення про помилку, а не перенаправляти на захист (серйозно, чому б не просто перенаправити? Чим більше я про це думаю, тим менше Я думаю, що це погана ідея).

— пільман

Я перехопив всю файлову систему, шукаючи текст цього кривавого повідомлення, щоб побачити, чи можу я там, де вони випилюють її, з випадковості я міг би вставити <javascriptтег і пощастить з таким чином зламати перенаправлення, але поки що ні кубики. Нічого з цього питання, схоже, не вирішується так, що слід інакше досить жорсткої Apache-

— чудовості

-1

Ви можете виправити це за допомогою mod-rewrite. Встановіть правило, що відповідає будь-якому. Дивіться цю відповідь на Stackoverflow

— трент
джерело

Ні, я вже пробував це, це не працює. Начебто він навіть не дістається до кроків ModRewrite, оскільки спочатку вдаряє невідповідність http / https.

— peelman

Hrm, тому я припускаю, що ви почали з вершини файлу apache config і працювали вниз, щоб побачити, що він викликає

— трент

Я практично запам’ятав весь sites-availableкаталог. Навіть якщо ви просто перенаправляєте його на дурниці або перенаправляєте на інший сайт, інший порт тощо, він просто продовжує завантажувати 400 поганих запитів.

— peelman