Верификационна верига. CC BY-SA 4.0
Инспекция на SSL трафика (дешифриране на SSL/TLS, анализ на SSL или DPI) става все по-актуална тема в корпоративния сектор. Идеята за дешифриране на трафик сякаш противоречи на самата концепция за криптография. Въпреки това фактите говорят за себе си: все повече компании използват технологии на DPI, обяснявайки това с необходимостта от проверка на съдържанието за заплахи, изтичане на данни и др.
Ако приемем, че внедряването на такава технология е наложително, следва да разгледаме начините за реализирането й по най-сигурния и добре управляван начин. Най-малко, не трябва да разчитате на сертификатите, например, които ви предоставя доставчикът на системата DPI.
Има един аспект на изпълнението, за който не всички знаят. Всъщност много хора наистина се удивяват, когато научат за него. Това е частен удостоверяващ център (ЦУ). Той генерира сертификати за дешифриране и повторно шифриране на трафика.
Вместо да разчитате на самоподписани сертификати или сертификати от устройства DPI, можете да използвате независим ЦУ от външен удостоверяващ център, като GlobalSign. Но първо, нека направим кратък преглед на самата проблема.
Какво е инспекция на SSL и защо се използва?
Все повече публични уебсайтове преминават на HTTPS. Например, според , в началото на септември 2019 година дялът на криптирания трафик в Русия е достигнал 83%.
За съжаление, криптирането на трафика все по-често се използва и от злонамерени лица, особено след като Let’s Encrypt предоставя хиляди безплатни SSL сертификати в автоматизиран режим. По този начин HTTPS се използва навсякъде — и заключването в адресната лента на браузъра вече не служи като сигурен индикатор за безопасност.
От тази перспектива производителите на решения DPI рекламират своя продукт. Те се внедряват между крайните потребители (т.е. вашите служители, разглеждащи уеб страници) и Интернет, филтрирайки злонамерен трафик. Вече на пазара съществуват редица такива продукти, но процесите по същество са еднакви. HTTPS трафикът преминава през проверяващо устройство, където се дешифрира и проверява за наличие на зловреден софтуер.
След завършване на проверката, устройството създава нова SSL сесия с крайния клиент за декриптиране и повторно криптиране на съдържанието.
Как работи процесът на декриптиране/повторно криптиране
За да декриптира и повторно криптира пакетите, преди да ги изпрати на крайния потребител, устройството за SSL инспекция трябва да може да издава SSL сертификати в движение. Това означава, че трябва да има инсталиран сертификат на ЦС.
За компанията (или отделно лице) е важно тези SSL сертификати да бъдат доверени в браузърите (т.е. да не предизвикват ужасни предупредителни съобщения, подобни на показаното по-долу). Поради това веригата на ЦС (или иерархия) трябва да е в хранилището за доверие на браузъра. Тъй като тези сертификати не се издават от обществено доверени центрове за сертификация, е необходимо ръчно да се предадат иерархиите на ЦС на всички крайни клиенти.
Предупредително съобщение за самоподписан сертификат в Chrome. Източник:
На компютри с 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
