Примушуйте https весь сайт, не перенаправляючи http на https

14

Було багато дискусій, поки я досліджував, як зробити весь сайт https. Найбільш відповідей було перенаправити http на https (файл .htaccess), що не годиться, оскільки не добре робити ту саму роботу двічі (два запити). Також "людина в середині" спочатку переходить на http, і я хочу, щоб мій сайт перейшов безпосередньо на https. Чи є інший спосіб зробити весь сайт https, і як це зробити? Наприклад, коли типи користувачів в example.com, що example.com автоматично переходить на https, не перенаправляючи спочатку з http чи іншого?

http  https 
— Марко Тамбурич
джерело
якщо ви не хочете, щоб люди переспрямовувались на https, що ви хочете, щоб це сталося замість цього?
— Майкл Хемптон
@MichaelHampton Можливо, я задаю питання новачкові, але я хочу практично "видалити" http, і це єдине, що існує - https. Або якщо це неможливо, я можу просто скористатися перенаправленням, якщо це досить добре для безпеки. Я чув, що перенаправлення http-> https не настільки добре, оскільки воно все ще є http, і трафік може перехоплюватися під час перенаправлення.
— Марко Тамбурич
Постійне перенаправлення HTTP 301 - ваш друг, просто не забудьте встановити термін дії.
— Марсель
Можна просто видалити http. Але потім користувач отримує лише повідомлення про відмову в з’єднанні, якщо вона не входить до https: // Для деяких сайтів це краще, оскільки безпека вище. Якщо доступна версія http, може статися, що файли cookie надсилаються з першим запитом незашифрованим. Для таких речей, як система електронної пошти компанії https only + навчання користувачів нормально, для загального сайту ви, ймовірно, втратите багато відвідувачів.
— Йозеф каже, що повернеться до Моніки
У Afaik це стало можливим за допомогою HTTP2, однак він все одно не уникне атаки ssl striping (описано у відповідях нижче).
— петерх

Відповіді:

20

Ні. Не можна магічно змусити браузер відвідувача вибрати правильний протокол. Переадресація - це спосіб зробити.

— Дженні Д
джерело
1
Щоб розширити цю відповідь, подумайте про перезапис URL-адрес та код статусу 301, як тут вказує Марк Хендерсон: serverfault.com/questions/570288/…
— Ryan Ries
— Marcel
22

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security дозволяє вашому серверу вказати, що доступ до домену має бути доступний лише через HTTPS. Це стосується лише наступних запитів, тому буде початкове завантаження HTTP, але майбутні запити завантажуватимуть HTTPS, навіть якщо хтось явно ввів HTTP.

IE ще не підтримує його, але всі інші спеціальності.

— ceejayoz
джерело
Він все ще не захищає від першого запиту.
— Дженні Д
3
@JennyD Я вже сказав це саме у своїй відповіді.
— ceejayoz
@JennyD Що ви маєте на увазі під «захистом»? MiM не може нічого проти перенаправлення http -> https, якщо вони не возиться з локальним dns / маршрутизацією та підробляють весь ваш домен. У цьому випадку це не має значення, чим ви займаєтесь, оскільки до ваших серверів ніколи не звертаються.
— Червоне сповіщення
2
@JennyD Ну, HSTS - це дійсно краще рішення, ніж ваша посада, де сказано, що "переспрямування - це спосіб це зробити". Перенаправлення може бути MITMed в будь-який час. Перенаправлення з HSTS може бути MITMed лише один раз на рік на кожного користувача + браузера (або незалежно від часу закінчення терміну придатності) - усі інші випадки його не запитують.
— ceejayoz
1
@MarkoTamburic Жодна причина, що ви не можете поєднати це.
— ceejayoz
7

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

Єдиний вірний спосіб запобігти цьому - взагалі не обслуговувати HTTP . Не відповідайте на порт 80, за винятком випадків, коли ви можете обслуговувати звичайну текстову сторінку, яка спрямовує користувача спробувати знову з HTTPS (але не надаючи посилання, яким зловмисник може маніпулювати). Це змусить користувача ввести https://свій браузер, тому він ініціює з'єднання з SSL та запобігає атаці MITM.

— Ендрю Шульман
джерело
3
Однак це є компромісом, оскільки більшість користувачів не збираються вводити текст https://. Натомість вони скажуть "так, сайт зламаний" і піде. Найкращий сценарій може www.example.comвідповідати як HTTP, так і HTTPS, але сам додаток працює на щось подібне admin.example.comлише з HTTPS.
— ceejayoz
Домовились. На практиці цього майже ніхто не робить.
— Ендрю Шульман
Я не розумію, як це було б більш стійким до МіМ. Якщо людина посередині може змінити вашу гіперпосилання, щоб вона вказувала десь інше, це означає, що він контролює вхідні пакети користувача. Він може так само легко перенаправляти на свій сайт або додавати будь-яку гіперпосилання, яку він хоче, незалежно від того, як має виглядати сайт.
— Червоне сповіщення
Але теоретично ні, якщо клієнт ініціює з'єднання з SSL.
— Ендрю Шульман
3
це правда - але якщо клієнт ініціює SSL, у OP немає проблем. Його проблема полягає в тому, коли вони ініціюють без SSL, і немає ніякого способу їх надійного переходу до SSL, якщо MiM активно саботує це.
— Червоне сповіщення
1

ceejayoz має найкращу відповідь, щоб запобігти конкретно згаданій атаці тут, але я хочу також зазначити, чого багато людей тут не вистачає, в основному, що HTTP має іншу частину вже з'ясовано. Ви хочете зробити постійне переадресацію 301. Це спонукає клієнта подавати додаткові запити на нову адресу. Так що так, якщо хтось введе неправильну URL-адресу, він зробить 2 запити, Але в майбутньому хороший клієнт повинен виявити запити до цієї URL-адреси та замість цього зробити правильний запит, щоб уникнути більше марних запитів. Проблема полягає в тому, що це лише для цієї точної URL-адреси. HSTS покращує цю схему, також кажучи: "протягом наступних n секунд також не допускати жодних незахищених з'єднань з цього домену".

Користувачі не повинні відвідувати чутливі сайти в незахищених місцях. Вони особливо не повинні підписуватись на них у небезпечних місцях. Це основні принципи безпеки користувачів, яким слід навчати так само, як "не відкривати вкладення з недовірених джерел". Які справді найкраща відповідь для запобігання MiM-атакам на сайти, які ніколи не відвідували.

В якості додаткового зауваження, деякі браузери покращують це, також говорячи, що певні відомі сайти завжди використовують HSTS. На жаль, ви не можете просто додати себе до цього списку легко.

Подальше читання: http://coderrr.wordpress.com/2010/12/27/canonical-redirect-pitfalls-with-http-strict-transport-security-and-some-solutions/

http://dev.chromium.org/sts

— krowe
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.