DPI (інспекція SSL) суперечить змісту криптографії, але фірми її впроваджують

Ланцюжок довіри. CC BY-SA 4.0 Yanpas

Інспекція трафіку SSL (розшифрування SSL/TLS, аналіз SSL або DPI) стає дедалі гарячішою темою обговорення у корпоративному секторі. Ідея розшифровки трафіку начебто суперечить самій концепції криптографії. Однак факт є фактом: все більше компаній використовують технології DPI, пояснюючи це необхідністю перевірки контенту на предмет зловредів, витоків даних і т.д.

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

Є один аспект реалізації, про який не всі знають. Насправді багато хто дійсно дивується, коли чують про нього. Це приватний центр сертифікації (ЦС). Він генерує сертифікати для дешифрування та повторного шифрування трафіку.

Замість того, щоб покладатися на самопідписані сертифікати або сертифікати з пристроїв DPI, ви можете використовувати виділений ЦС від центру сертифікації, такого як GlobalSign. Але спершу давайте зробимо невеликий огляд самої проблеми.

Що таке SSL-інспекція та чому вона використовується?

Дедалі більше публічних веб-сайтів переходять на HTTPS. Наприклад, за статистиці Chrome, На початку вересня 2019 року частка зашифрованого трафіку в Росії досягла 83%.

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

З цих позицій просувають свій продукт виробники рішень DPI. Вони впроваджуються між кінцевими користувачами (тобто вашими співробітниками, які переглядають веб-сторінки) та Інтернетом, відфільтровуючи шкідливий трафік. На сьогоднішній день на ринку існує низка таких продуктів, але процеси по суті однакові. Трафік HTTPS проходить через пристрій перевірки, де він розшифровується та перевіряється на наявність шкідливих програм.

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

Як працює процес розшифрування/повторного шифрування

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

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

Попереджувальне повідомлення для підписаного сертифіката в Chrome. Джерело: BadSSL.com

На комп'ютерах з Windows можна використовувати Active Directory та групові політики, але для мобільних пристроїв процедура складніша.

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

Найкращий варіант: приватний, виділений кореневий сертифікат від стороннього ЦС

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

Спрощена архітектура для виділених клієнтських кореневих сертифікатів

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

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

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

Незважаючи на всі протиріччя, підприємства все частіше впроваджують SSL-інспекцію трафіку як частину внутрішньої чи приватної інфраструктури PKI. Інші варіанти використання приватної PKI — випуск сертифікатів для автентифікації пристроїв або користувачів, SSL для внутрішніх серверів, а також різні конфігурації, які не дозволені у загальнодоступних довірених сертифікатах відповідно до вимог CA/Browser Forum.

Браузери пручаються

Потрібно зауважити, що розробники браузерів намагаються протистояти цій тенденції та захистити кінцевих користувачів від MiTM. Наприклад, кілька днів тому Mozilla ухвалила рішення увімкнути за промовчанням протокол DoH (DNS-over-HTTPS) в одну з наступних версій браузера Firefox. Протокол DoH приховує DNS-запити від DPI-системи, ускладнюючи SSL-інспекцію.

Про аналогічні плани 10 вересня 2019 року оголосила Google для браузера Chrome.

Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.

Як ви вважаєте, компанія має право перевіряти SSL-трафік своїх співробітників?

• Так, за їхньою згодою

• Ні, запитувати таку згоду незаконно та/або неетично

Проголосували 122 користувачів. Утрималися 15 користувачів.

Джерело: habr.com