Чи сповільнить аутентифікацію через HTTPS мою програму?

Я будую веб-додаток та RESTful веб-сервіс.

Я читав різні статті про найкращий спосіб аутентифікації запитів до веб-сервісу.

Найкращим варіантом для мене, здається, є використання базової автентифікації HTTP. Практично в кожній статті, яку я прочитав, сказано, що автентифікація повинна бути зашифрована через SSL або еквівалент.

Я не зовсім впевнений, що це стосується. Чи означає це, що весь мій веб-сервіс повинен бути на захищеному сервері? Це сповільнить справи?

Перш за все, спробуйте зрозуміти, як працюють SSL (HTTPS) та HTTP-аутентифікація.

Звичайні методи аутентифікації HTTP (Digest, Basic та будь-які форми + схема аутентифікації на основі файлів cookie, яку ви можете впровадити поверх HTTP) самі по собі не є безпечними, оскільки вони надсилають інформацію про автентифікацію більш-менш чітким текстом. Незалежно від того, чи є дані в полях POST або заголовках, і чи застосовується базове кодування64, в цьому плані зовсім не має значення, пароль чітко видно для всіх, хто має доступ до мережевого трафіку. Це означає, що аутентифікація HTTP по ненадійному каналу марна: все, що потрібно, щоб зловмисник прочитав ваш пароль, - це невелике обнюхання мережі.

SSL реалізує захищений канал зв'язку через невід'ємно незахищений канал. Це працює приблизно так:

1. Сервер надсилає підписаний сертифікат
2. Клієнт підтверджує сертифікат щодо списку відомих хороших ключів підпису; підписи сертифікатів можуть бути ланцюговими, так що кожен вузол говорить "якщо підпис, який мене підписує, хороший, то я так і є", але в кінцевому підсумку ланцюг повинен вирішити один із декількох довірених авторитетів, попередньо налаштованих на клієнта.
3. Клієнт використовує відкритий ключ шифрування сервера для надсилання загальної таємниці
4. Сервер розшифровує загальну таємницю за допомогою приватного ключа (оскільки лише легітимний сервер має приватний ключ, інші сервери не зможуть розшифрувати спільний секрет)
5. Клієнт надсилає фактичні дані запиту, зашифровані за допомогою спільного секрету
6. Сервер розшифровує дані запиту, після чого надсилає зашифровану відповідь
7. Клієнт розшифровує відповідь і представляє її користувачеві.

Зверніть увагу на кілька важливих моментів тут:

• Ланцюг сертифікатів дозволяє клієнтам переконатися, що сервер, з яким вони спілкуються, справжній, а не хтось перехоплює їх запити. Ось чому ви повинні придбати справжній сертифікат SSL, і чому браузери накидають на вас страхітливі попередження, коли ви потрапляєте на сайт, на якому використовується недійсний, закінчений термін чи неправильний сертифікат: все шифрування у світі не допомагає, якщо ви розмовляючи з невірною людиною.
• Публічне / приватне шифрування, яке використовується для обміну секретом, гарантує, що успішне спілкування працюватиме лише між цією певною парою клієнта та сервера: обнюхані мережеві пакети будуть зашифровані, і вони потребують приватного ключа сервера, щоб отримати дані.
• Для більшої частини запиту використовується симетричне шифрування, оскільки воно має значно нижчу ефективність, ніж шифрування приватного / відкритого ключа. Ключ (загальний секрет) обмінюється за допомогою шифрування приватного / відкритого ключа, оскільки це єдиний спосіб зробити це безпечним способом (за винятком транспортування його по окремому каналу, наприклад кур'єрській службі).

Тож очевидно, що тут задіяні деякі накладні витрати, але це не так вже й погано, як ви могли б подумати - це здебільшого на шкалі, коли "кинути на нього більше обладнання" - це відповідна відповідь, якщо тільки ви не готуєтесь до абсолютно великої кількості трафіку ( думаю, Google або Facebook). За звичайних обставин, тобто типового використання веб-додатків, накладні витрати SSL незначні, і, отже, як тільки у вас є будь-які конфіденційні дані, краще просто запустити все через SSL, включаючи ресурси. SSL також є єдиним життєздатним способом забезпечення HTTP-трафіку; інші методи просто не настільки стандартизовані і, таким чином, не підтримуються широко, і ви абсолютно не хочете реалізовувати ці речі самостійно, адже, чесно кажучи, просто занадто просто їх помилити.

TL; DR: Так, SSL + Basic Authentication - хороша ідея, так, вам потрібен захищений сервер (і дійсний сертифікат ), так, це трохи сповільнить справи, але ні, це не те, що потрібно турбуватися правильно зараз.

HTTPS (SSL) не є автентифікацією користувача FYI. Він просто забезпечує шифрування між двома кінцевими точками.

Але так, від цього є маленький крихітний наліт (хоча це недостатньо, щоб гарантувати зміну планів / обладнання). Дивіться тут:

/programming/548029/how-much-overhead-does-ssl-impose

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

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

Основна автентифікація - це встановлення імені користувача та пароля у заголовку http-запиту. Якщо ви не використовуєте SSL або еквівалент, то це ім'я користувача та пароль надсилаються у простому тексті і є дрібницею для того, щоб хто-небудь вкрав.

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

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

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

Також він посилається на цю статтю про тематичне дослідження Gmail, цитуючи таке:

У січні цього року (2010 р.) Gmail перейшов на використання HTTPS для всього за замовчуванням. Раніше це було запроваджено як варіант, але тепер усі наші користувачі використовують HTTPS, щоб захищати електронну пошту між своїми браузерами та Google постійно. Для цього нам не довелося розгортати ні додаткових машин, ні спеціального обладнання. На наших виробничих фронтальних машинах на SSL / TLS припадає менше 1% завантаження процесора, менше 10 КБ пам'яті на з'єднання і менше 2% накладних витрат мережі. Багато людей вважають, що SSL займає багато процесорного часу, і ми сподіваємося, що вищезгадані цифри (вперше загальнодоступні) допоможуть відмовитись від цього.

Він також згадує деякі недавні вдосконалення браузера на кешування сторінок через HTTPS .

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

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

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

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

Примітка: "Аутентифікація HTTPS" (про яку ви згадували у назві) вводить в оману - це може посилатися на автентифікацію сертифікату клієнтської служби SSL, яка має мало спільного з текстом вашого запитання та має власний набір переваг та проблем. Ви, мабуть, не хочете цього торкатися.

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

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