SSL та непорозуміння "людина посередині"

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

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

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

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

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

Атаки "людина посередині" на SSL дійсно можливі лише за умови порушення однієї з передумов SSL, ось кілька прикладів;

• Ключ сервера викрадено - означає, що зловмисник може бути сервером, і клієнт не може про це знати.

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

• Клієнт не заважає правильно перевірити сертифікат у списку надійних центрів сертифікації - кожен може створити центр сертифікації. Без жодної перевірки "Автомобілі та сертифікати Бена" виявляться такими ж дійсними, як і Verisign.

• Клієнт зазнав нападу, а в його довірені кореневі повноваження було введено підроблений ЦС - дозволяє зловмиснику генерувати будь-який сертифікат, який йому подобається, і клієнт йому довірятиме. Зловмисне програмне забезпечення, як правило, робить це, щоб, наприклад, перенаправити вас на фальшиві банківські сайти.

Особливо №2 досить неприємний, навіть якщо ви платите за надійний сертифікат, ваш сайт жодним чином не буде заблокований для цього сертифіката, вам доведеться довіряти всім ЦС у браузері клієнта, оскільки будь-який з них може сформувати підроблений сертифікат для ваш веб-сайт, який настільки ж дійсний. Він також не вимагає доступу ні до сервера, ні до клієнта.

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

Сервер відповідає ланцюжком сертифікатів X.509 та цифровим підписом, підписаним власним приватним ключем.

Потім клієнт приймає рішення, якщо вона довіряє серверу

Правильно.

шифрує якийсь довільний ключ сеансу за допомогою відкритого ключа і відправляє його назад.

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

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

Немає.

Сервер робить це

Немає.

а потім починається сесія HTTPS.

TLS / SSL починається сесія, але є кілька кроків першими.

Отже, якщо я правильно зазначив вище, питання полягає в тому, як може статися атака "людина посередині" за такого сценарію?

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

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

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

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

Правильно.

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

Немає.

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

Це настільки ж безпечно, як ім’я користувача / пароль, які набагато легше просочити, ніж приватний ключ.

Будь-хто, хто перебуває між клієнтом та сервером, може зробити інтерактивну атаку на https. Якщо ви вважаєте, що це малоймовірно або рідко, врахуйте, що існують комерційні продукти, які систематично розшифровують, сканують та перешифровують весь SSL-трафік через Інтернет-шлюз.. Вони працюють, надсилаючи клієнту ssl-сертифікат, створений на льоту, з деталями, скопійованими з "справжнього" ssl-сертифікату, але підписаними іншим ланцюжком сертифікатів. Якщо цей ланцюжок закінчується будь-яким із надійних центрів сертифікації браузера, цей MITM буде невидимим для користувача. Ці товари в основному продаються компаніям для "захисту" (поліції) корпоративних мереж і повинні використовуватися з відома та згоди користувачів. Однак технічно ніщо не зупиняє їх використання провайдерами або будь-якими іншими операторами мережі. (Було б безпечно припустити, що NSA має принаймні один надійний ключ підписання CA ).

Якщо ви обслуговуєте сторінку, ви можете включити заголовок HTTP із зазначенням, яким відкритим ключем слід підписати сторінку. Це може допомогти попередити користувачів про MITM про їхнє "безпечне" з'єднання, але це техніка довіри до першого використання. Якщо Боб ще не має запису про "справжній" PIN-код відкритого ключа, Меллорі просто переписує заголовок pkp у документі. Список веб-сайтів, що використовують цю технологію (HPKP), гнітюче короткий. До їх складу входить Google і Dropbox. Зазвичай https-перехоплюючий шлюз буде махати сторінками кількох великих надійних сайтів, які використовують HPKP. Якщо ви побачите помилку HPKP, коли не очікуєте її, будьте обережні.

Що стосується паролів, то все на з’єднанні https захищене https, крім доменного імені, яке повинно бути чітким, щоб запит можна було направити. Загалом, рекомендується не вводити паролі в рядок запиту, де вони можуть зависати в журналах, закладках тощо. Але рядок запиту не видно, якщо не порушено https.

1. Правильно
2. Не так правильно. При такій атаці сервер itermediate отримує ваш запит і надсилає його до місця призначення від імені вас. а потім відповісти вам результатом. Насправді це сервер "людина посередині", який забезпечує безпечне з'єднання з вами, а не фактичний сервер, з яким ви збираєтеся спілкуватися. ось чому ви ПОВИННІ завжди перевіряти, чи є сертифікат дійсним та довіреним.
3. може бути правильним
4. Якщо ви впевнені, що захищене з’єднання є надійним, тоді безпечно надсилати ім’я користувача / пароль.

Все, що ви сказали, є правильним, крім частини про ключ сеансу. Сенс CA - перемогти атаку "людина посередині" - все інше робить сама SSL. Аутентифікація клієнта є альтернативою схемі імені користувача та пароля.