Чи є якісь причини не застосовувати HTTPS на веб-сайті?

Веб-сайт, на який я часто звертався, нарешті вирішив включити TLS до своїх серверів, тільки не мандат, як це робить багато веб-сайтів. Підтримувач стверджує, що TLS повинен бути необов'язковим. Чому?

На своєму власному веб-сайті я давно налаштовував TLS та HSTS з довгими періодами, а слабкі пакети шифрів відключені. Доступ до прямого тексту гарантується за допомогою HTTP 301 до захищеної TLS версії. Чи впливає це на мій веб-сайт негативно?

Існує кілька вагомих причин використовувати TLS

(і лише кілька граничних причин цього не робити).

• Якщо на сайті є автентифікація, використовуйте HTTP-експозицію для крадіжки сеансів та паролів.

• Навіть на статичних, лише інформаційних сайтах, використання TLS гарантує, що ніхто не підробляє дані.

• Починаючи з I / O 2014 року , Google вжив декілька кроків, щоб заохотити всі сайти використовувати HTTPS:

  • Google допомагає веб-майстрам налаштувати свої сервери більш безпечно, але також використовував HTTPS як сигнал ранжування .
  • Зовсім недавно Google Chrome почав позначати HTTP-сайти як незахищені , як частину довгострокового плану позначати всі HTTP-сайти як незахищені .
  • У лекції команди Mythbusting HTTPS команди розробників Google Chrome чітко викладено їхнє ставлення.

• Блог Mozilla Security також оголосив про видалення не захищеного HTTP , зробивши всі нові функції доступними лише для захисту веб-сайтів і поступово припиняючи доступ до функцій браузера для незахищених веб-сайтів, особливо функцій, що становлять ризики для безпеки та конфіденційності користувачів .

Існує також кілька вагомих причин для застосування TLS

Якщо у вас вже є довірений сертифікат, чому б не завжди ним користуватися? Практично всі поточні браузери підтримують TLS та мають встановлені кореневі сертифікати. Єдиною проблемою сумісності, яку я фактично бачив за роки, були пристрої Android та відсутніх проміжних авторизованих сертифікатів, оскільки Android лише довіряє кореневим ЦА безпосередньо. Це легко уникнути, налаштувавши сервер на відправку ланцюжка сертифікатів назад до кореневого центру.

Якщо ваш обслуговуючий персонал все-таки хоче дозволити HTTP-з'єднання без прямого 301 Moved Permanently, скажімо, для забезпечення доступу з деяких дійсно старих браузерів або мобільних пристроїв, браузер не може знати, що у вас навіть налаштований HTTPS . Крім того, ви не повинні розгортати сувору безпеку транспорту HTTP (HSTS) без 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

Проблема різних сайтів, налаштованих для обох протоколів, розпізнається The Tor Project та Electronic Frontier Foundation і вирішується багатоповерховим розширенням HTTPS Everywhere :

Багато веб-сайтів в Інтернеті пропонують обмежену підтримку шифрування через HTTPS, але ускладнюють їх використання. Наприклад, вони можуть замовчувати незашифрований HTTP або заповнювати зашифровані сторінки посиланнями, які повертаються на незашифрований сайт.

Змішаний контент також був величезною проблемою через можливі атаки XSS на сайти HTTPS за допомогою зміни JavaScript або CSS, завантажених через незахищене HTTP-з'єднання. Тому в наш час усі основні браузери попереджають користувачів про сторінки зі змішаним вмістом і відмовляються автоматично завантажувати його. Це ускладнює підтримку сайту без 301перенаправлень на HTTP: ви повинні переконатися, що кожна HTTP-сторінка завантажує лише HTTP-контекст (CSS, JS, зображення тощо), а кожна HTTPS-сторінка завантажує лише вміст HTTPS. Це надзвичайно важко досягти при однаковому вмісті обох.

У цей день і вік TLS + HSTS - це маркери, якими веб-сайт управляється професіоналами, яким можна довіряти, що вони роблять. Це новий мінімальний стандарт надійності, про що свідчить Google, заявляючи, що вони забезпечать позитивний рейтинг для сайтів, які так роблять.

З іншого боку - максимальна сумісність. Там ще є старші клієнти, особливо в тих частинах світу, які не є США, Європа чи Китай. Звичайний HTTP завжди працюватиме (хоча, не завжди добре ; це вже інша історія).

TLS + HSTS: Оптимізація для рейтингу пошукових систем
Простий HTTP: Оптимізація сумісності

Залежить від того, що для вас важливіше.

Існує одна вагома причина, щоб веб-сайти, які читають лише для читання, не використовували HTTPS.

• Веб-кеші не можуть кешувати зображення, що транспортуються через HTTPS.
• Деякі частини світу мають дуже низькі швидкісні міжнародні зв'язки, тому залежать від кеш-пам'яті.
• Хостинг зображень з іншого домену вимагає навичок, яких ви не можете очікувати, що оператори мають невеликі веб-сайти, які читають лише вони.

Підтримувач стверджує, що TLS повинен бути необов'язковим. Чому?

Щоб справді знати відповідь на це питання, ви повинні їх задати. Ми можемо, однак, зробити деякі здогадки.

У корпоративному середовищі звичайно для ІТ встановлювати брандмауер, який перевіряє вхідний та вихідний трафік на предмет зловмисного програмного забезпечення, підозрілої діяльності, схожої на CnC, вмісту, який вважається неприйнятним для роботи (наприклад, порнографії) тощо. Це стає набагато складніше, коли трафік шифрується. По суті є три можливі відповіді:

1. Відмовтеся від моніторингу цього трафіку.
2. Встановіть кореневий сервісний центр на машини користувачів, щоб ви могли виконати розшифровку та перевірку MitM.
3. Оптовий блок зашифрованого трафіку.

Для стурбованого систематика жоден із цих варіантів не є особливо привабливим. Існує велика кількість загроз, які атакують корпоративну мережу, і їхня робота - захистити компанію від них. Однак, блокування дуже багатьох сайтів цілком викликає гнів користувачів, а встановлення кореневого центру може бути трохи невдалим, оскільки воно вводить користувачів у життя щодо конфіденційності та безпеки. Я пам’ятаю, що бачив (вибачте, не можу знайти нитку) прохання про систематичне редагування reddit, коли вони вперше вмикали HSTS, оскільки він опинився саме в цій ситуації, і не хотів блокувати все Reddit просто тому, що його змусив бізнес щоб заблокувати порнодиски, орієнтовані на порно.

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

Все зводиться до ваших вимог безпеки, вибору користувача та ризику неявного пониження рівня. Відключення старих шифрів на стороні сервера значною мірою необхідне, оскільки браузери із задоволенням потраплять до абсолютно жахливих шифрів на стороні клієнта в ім'я користувальницької роботи / зручності. Переконайтесь, що нічого вашого, що залежить від захищеного каналу для користувача, неможливо досягти небезпечним методом, звичайно, також дуже добре.

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

Сьогодні є вбудовані системи, які не мають можливості використовувати TLS поза коробкою, або ті, які застрягли в старих реалізаціях (я думаю, це жахливо погано, що це так, але як користувач живлення [вбудувати вбудований пристрою], я іноді не можу це змінити).

Ось цікавий експеримент: спробуйте завантажити останню версію LibreSSL з висхідного сайту OpenBSD через HTTPS з досить старою реалізацією TLS / SSL. Ви не зможете. Я спробував днями на пристрої зі старішою версією OpenSSL з 2012 року або більше, тому що хотів оновити цю вбудовану систему на більш безпечну, нову інформацію з джерела - у мене немає розкоші заздалегідь вбудований пакет. Повідомлення про помилки, коли я намагався, не були зовсім інтуїтивно зрозумілими, але я вважаю, що це було тому, що мій старший OpenSSL не підтримував потрібні речі.

Це один із прикладів, коли перехід лише HTTPS може насправді нанести шкоду людям: якщо у вас немає розкоші останніх попередньо створених пакетів і хочете вирішити проблему самостійно, будуючи з джерела, ви закриваєтесь. На щастя, у випадку LibreSSL ви можете відмовитися від явного запиту HTTP. Звичайно, це не врятує вас від того, хто зловмисник уже переписує ваш трафік, здатний замінити вихідні пакети компрометованими версіями та переписати всі контрольні суми в телах HTTP, що описують пакети, доступні для завантаження на веб-сторінках, які ви переглядаєте, але це все ще корисно більш поширений випадок.

Більшість із нас не є одним незахищеним завантаженням, яке не належить APT (Advanced Persistent Thread: жаргон безпеки для національних спецслужб та інші надзвичайно добре забезпечені кіберзагрозами). Іноді я просто хочу отримати wgetякусь звичайну текстову документацію або невелику програму, джерело якої я можу швидко перевірити (наприклад, мої власні крихітні утиліти / скрипти на GitHub) на вікно, яке не підтримує останні пакети шифрів.

Особисто я запитав би це: чи є ваш вміст таким, щоб людина могла законно вирішити "я добре, коли я маю доступ до публічних знань"? Чи є ймовірний ймовірний реальний ризик для нетехнічних людей, які випадково переходять на HTTP для вашого вмісту? Обґрунтуйте ваші вимоги до безпеки, примусові вимоги конфіденційності для ваших користувачів та ризик неявного зниження по відношенню до здатності користувачів, які розуміють ризики, роблячи обґрунтований вибір у кожному конкретному випадку, залишатися незахищеними. Цілком правомірно сказати, що для вашого сайту немає жодної вагомої причини не застосовувати HTTPS - але я вважаю, що справедливо сказати, що все ще є хороші випадки використання для звичайного HTTP.

Тут багато дискусій щодо того, чому tls добре - але це ніколи не запитували, як у первісному дописі.

Maxthon задав 2 питання:

1) чому має випадковий, не названий сайт, який вирішив підтримувати присутність як http, так і https

2) Чи має негативний вплив на Maxthon подання лише 301 відповіді на http-запити

Що стосується першого питання, ми не знаємо, чому провайдери вирішили зберегти як http, так і https сайти. Причин може бути багато. Окрім пунктів про сумісність, розподілене кешування та деякі підказки про геополітичну доступність, також розглядаються питання інтеграції вмісту та уникнення негарних повідомлень веб-переглядача щодо незахищеного вмісту. Як зазначав Альваро, TLS - це лише вершина айсберга щодо безпеки.

Однак друге питання відповідає. Розкриття будь-якої частини вашого веб-сайту через http, коли йому фактично потрібні https для безпечної роботи, забезпечує експлуатований вектор для атак. Однак має сенс підтримувати це, щоб визначити, куди трафік неправильно спрямований до порту 80 на вашому веб-сайті та виправити причину. Тобто є як негативний вплив, так і можливість позитивного впливу, чистий результат залежить від того, чи виконуєте ви свою роботу адміністратора.

Sysadmin1138 говорить, що https впливає на рейтинги SEO. Хоча Google заявляв, що це впливає на рейтинг, але єдині надійні дослідження, які я бачив, припускають, що різниця невелика. Це не допомагає людям , які повинні знати краще стверджують , що, так як високий рейтинг сайтів, більш імовірно , щоб мати присутність HTTPS, присутності HTTPS тому покращує ранжування.

Раніше мені довелося використовувати HTTP, а не HTTPS, тому що я хотів, щоб <embed>сторінки з інших місць, які самі надходили через HTTP, і не діятимуть інакше.

Це не хороша причина, оскільки це означає , що у вас є погані / зламані / небезпечні клієнти, але якщо є автоматизовані процеси доступу до ресурсів з допомогою існуючих http://адрес, цілком можливо , що деякі з них навіть не підтримують протокол HTTPS (наприклад , BusyBox wget, який Байдуже не матиме внутрішню підтримку TLS і лише нещодавно додав її через дочірній процес openssl), і він би порушився, якби їм дали переспрямування на URL-адресу https, яке вони не можуть переслідувати.

Мені б сподобатися вирішити цю можливість, написавши правило про переадресацію, щоб виключити перенаправлення невідомих (або відомих застарілих) рядків User-Agent і дозволити їм отримати доступ до вмісту через http, якщо вони хочуть, щоб фактичні веб-переглядачі могли отримати користь примусові https / hsts.

Є дуже мало вагомих причин використання HTTP замість HTTPS на веб-сайті. Якщо ваш веб-сайт обробляє транзакції будь-якого виду або зберігає будь-які чутливі або особисті дані, вам потрібно абсолютно використовувати HTTPS, якщо ви хочете, щоб ці дані були захищені. Єдиною гідною причиною, яку я б бачив у тому, щоб не застосовувати HTTPS, є те, що ваш веб-сайт покладається на кешування, оскільки HTTPS не працює з кешуванням. Однак, для забезпечення безпеки вашого веб-сайту часто варто принести трохи ефективності. Можливо також, що ваші клієнти можуть не підтримувати HTTPS, але насправді у 2017 році вони повинні.