DPI (инспекция SSL) противоречи на смисъла на криптографията, но компаниите я внедряват

Верига на доверие. CC BY-SA 4.0 Yanpas

Инспекция на SSL трафика (дешифриране на SSL/TLS, анализ на SSL или DPI) става все по-актуална тема в корпоративния сектор. Идеята за дешифриране на трафика изглежда противоречи на самата концепция на криптографията. Въпреки това, фактите са си факти: все повече компании използват технологии DPI, оправдавайки това с необходимостта от проверка на съдържанието за злонамерен софтуер, изтичане на данни и т.н.

Ако приемем за даденост, че е необходимо да се внедри такава технология, следва поне да разгледаме начина, по който да го направим по максимално безопасен и управляван начин. Поне да не разчитаме на сертификатите, например, които ви предоставя доставчикът на DPI системата.

Има един аспект на реализацията, за който не всички знаят. Всъщност много хора наистина се изненадват, когато чуят за него. Това е частен Център за сертификация (ЦС). Той генерира сертификати за дешифриране и повторно шифриране на трафика.

Вместо да разчитате на самоподписани сертификати или сертификати от устройства DPI, можете да използвате Dedicated CA от външен център за сертификация, като 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