Apache: перевірити ланцюжок довіри SSL для запобігання MITM-атак?

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

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

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

Я думаю, що це питання буде більш підходящим для security.stackexchange.com, де тема MITM обговорюється в багатьох питаннях. Але все ж таки:

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

У разі перехоплення SSL клієнтом TLS з точки зору сервера є SSL-перехоплюючий брандмауер / AV. Таким чином, проблема на стороні сервера полягає в тому, щоб виявити, розмовляє він із очікуваним клієнтом (браузером) чи ні (брандмауер / AV). Найбезпечніший спосіб зробити це - використовувати сертифікати клієнта для автентифікації клієнта - і насправді перехоплення SSL не буде працювати, якщо використовується автентифікація клієнта, тобто рукостискання TLS не вдасться, оскільки MITM не в змозі надати очікуваний клієнтський сертифікат.

Лише клієнтські сертифікати використовуються рідко. Крім того, невдале рукостискання TLS не означає, що клієнт може спілкуватися з сервером без перехоплення SSL, але клієнт взагалі не може спілкуватися з сервером. Альтернативним способом було б використання певної евристики для виявлення типу клієнта TLS на основі відбитків пальця рукостискання TLS, тобто виду та порядку шифрів, використання конкретних розширень ... Хоча SSL-перехоплюючий проксі теоретично міг наслідувати оригінал ClientHello прекрасно більшість не знає. Див. Також Виявлення "людина-посередині" на стороні сервера для HTTPS або розділ III Евристика впровадження TLS в "Вплив безпеки перехоплення HTTPS" .

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

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

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

Як я можу перевірити ланцюжок довіри на стороні сервера?

Ви не можете. Це робиться на стороні клієнта.

Залежно від випадку використання, ви можете зробити RFC 7469 HTTP- відкриття відкритого ключа, в якому ви надіслали клієнту додатковий заголовок із переліком (хешами) ваших фактичних SSL-сертифікатів або сертифікатів ЦС, які ви використовуєте.

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

Ви МОЖЕТЕ (вид), але справжнє питання полягає в тому, чи ПОТРІБНИТИ Ви .

Але будьте обережні, це ніде не так просто, як зміна прапора в apache.conf.

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

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

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

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

Крім того, оскільки компанії, які використовують проксі-сервери TLS MiTM, також зазвичай повністю керують клієнтським комп'ютером, вони можуть так само легко встановити екран і кейлоггер, щоб просто записати відео про все, що бачить користувач, і записати всі натискання клавіш (та рухи миші), які користувач вводить. Як бачите, коли зловмисник є клієнтом, не існує абсолютно безпечного способу його обдурити. Це справді лише питання, скільки вони будуть турбувати ... І деякі рішення вище, можливо, будуть досить хорошими для вас.