Чому б не використовувати HTTPS для всього?

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

Якщо я вже використовував HTTPS для частини сайту, чому б я не хотів використовувати його для всього сайту?

Це пов'язане питання: Чому https використовується лише для входу? , але відповіді не задовільні. Відповіді передбачають, що ви не змогли застосувати https до всього сайту.

Я можу припустити пару причин.

• Деякі браузери можуть не підтримувати SSL.
• SSL може дещо знизити продуктивність. Якщо користувачі завантажують великі, загальнодоступні файли, може бути системне навантаження для їх шифрування кожного разу.

На додаток до інших причин (особливо щодо продуктивності) ви можете розміщувати лише один домен на IP-адресу * під час використання HTTPS.

Один сервер може підтримувати кілька доменів у HTTP, оскільки заголовк HTTP сервера дозволяє серверу знати, з яким доменом відповідати.

З HTTPS сервер повинен запропонувати клієнту свій сертифікат під час початкового рукостискання TLS (що до запуску HTTP). Це означає, що заголовок Сервера ще не надісланий, тому сервер не може знати, який домен запитується та на який сертифікат (www.foo.com чи www.bar.com) відповісти.

* Зноска: технічно ви можете розміщувати кілька доменів, якщо розміщуєте їх на різних портах, але це, як правило, не варіант. Ви також можете розмістити декілька доменів, якщо у вашому сертифікаті SSL міститься загальна карта. Наприклад, ви можете розмістити як foo.example.com, так і bar.example.com із сертифікатом * .example.com

SSL / TLS використовується не досить часто. HTTPS потрібно використовувати протягом усього сеансу , жоден момент не може надсилати ідентифікатор сесії через HTTP. Якщо ви використовуєте лише https для входу в систему, то ви явно порушуєте OWASP топ-10 за 2010 рік "A3: Зламана автентифікація та управління сесіями".

Чому б не надіслати кожну пошту від равлика у непрозорому непрозорому конверті зареєстрованою поштою? Хтось із поштового відділення завжди матиме особисту опіку над ним, тож ви можете бути впевнені, що ніхто не лунає на вашу пошту. Очевидно, що відповідь полягає в тому, що хоча частина пошти коштує витрат, більшість повідомлень не є. Мені все одно, чи хтось прочитає моє "Рада, що ти вийшов із в'язниці!" листівка дядьку Джо.

Шифрування не безкоштовне, і це не завжди допомагає.

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

На мою думку, HTTPS слід використовувати лише тоді, коли це неминуче необхідно, або тому, що запит чи відповідь потрібно захистити від проміжного прослуховування. Як приклад, подивіться на Yahoo! домашня сторінка. Незважаючи на те, що ви зареєстровані, більшість вашої взаємодії буде здійснюватися через HTTP. Ви маєте автентифікацію на HTTPS і отримуєте файли cookie, які підтверджують вашу особу, тому HTTPS для читання новин вам не потрібен.

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

Для посилань з високою затримкою для початкового рукостискання TLS необхідні додаткові тури для зворотного підтвердження ланцюга сертифікатів (включаючи надсилання будь-яких проміжних сертифікатів), узгодити набір шифрів та встановити сеанс. Після встановлення сеансу наступні запити можуть використовувати кешування сеансу для зменшення кількості туди-назад, але навіть у цьому кращому випадку все-таки більше зворотних поїздок, ніж вимагає звичайного HTTP-з'єднання. Навіть якщо операції шифрування були безкоштовними, туди й назад не можна, і це може бути помітно через повільніші мережеві зв’язки, особливо якщо сайт не використовує http-конвеєр. Для користувачів широкосмугового зв'язку в добре пов'язаному сегменті мережі це не є проблемою. Якщо ви робите міжнародний бізнес, запрошення https може легко спричинити помітні затримки.

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

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

Можливо, існують оперативні міркування, такі як адміністративні обмеження на трафік https (думаю, проміжні фільтри вмісту ... тощо), можливо, деякі корпоративні чи урядові норми. Деяке корпоративне середовище вимагає розшифровки даних по периметру, щоб запобігти витоку інформації ... втручання в точку доступу та подібні системи доступу до Інтернету, не здатні вводити повідомлення в транзакції https. Зрештою, на мій погляд, причини, щоб не виходити https за замовчуванням, ймовірно, будуть зовсім невеликими.

https - більш ресурсний, ніж звичайний http.

Це вимагає більше як від серверів, так і від клієнтів.

Якщо весь сеанс зашифрований, ви не зможете використовувати кешування для статичних ресурсів, таких як зображення та js на рівні проксі, наприклад, провайдер.

Ви повинні використовувати HTTPS скрізь, але ви втратите наступне:

1. Ви точно не повинні використовувати компресію SSL або компресію HTTP над SSL через атаки BREACH та CRIME. Тож не стискайте, якщо ваша відповідь містить ідентифікатори сесії або csrf. Ви можете пом'якшити це, розмістивши статичні ресурси (зображення, js, css) на домені, що не містить файлів cookie, та застосуйте там стиснення. Ви також можете використовувати HTML мінімізацію.

2. Один сертифікат SSL, одна IP-адреса, за винятком випадків, коли використовується SNI, який працює не у всіх браузерах (старий Android, blackberry 6 тощо).

3. Ви не повинні розміщувати зовнішній вміст на своїх сторінках, які не надходять через SSL.

4. Ви втрачаєте вихідний заголовок HTTP Referer, коли браузер переходить на сторінку HTTP, що може бути або не бути проблемою для вас.

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

Це також може заплутати кінцевих користувачів, якщо всі адреси використовуються, https://а не звичні http://. Також дивіться цю відповідь:

Чому б не завжди використовувати https при включенні файлу js?

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

Окрім відповіді WhirlWind, слід враховувати вартість та застосовність сертифікатів SSL, проблеми доступу (можливо, хоча й малоймовірно, що клієнт може не мати можливості спілкуватися через порт SSL) тощо.

Використання SSL не є гарантованою ковдрою безпеки. Цей тип захисту потрібно вбудовувати в архітектуру програми, а не намагатися покластися на якусь магічну кулю.

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

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

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

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

Примітка. Я не впевнений, що це стосується браузера, але це, безумовно, трапляється з моїм браузером Firefox.

Windows Server 2012 з IIS 8.0 тепер пропонує SNI, що є індикацією імені сервера, що дозволяє розміщувати кілька веб-додатків SSL в IIS на одному IP-адресі.