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

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

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

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

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

Вместо да разчитате на самоподписани сертификати или сертификати от DPI устройства, можете да използвате специален CA от сертифициращ орган на трета страна, като GlobalSign. Но първо, нека направим кратък преглед на самия проблем.

Какво е SSL проверка и защо се използва?

Все повече публични уебсайтове преминават към HTTPS. Например според Статистика на Chrome, в началото на септември 2019 г. делът на криптирания трафик в Русия достигна 83%.

За съжаление криптирането на трафика все повече се използва от нападателите, особено след като Let's Encrypt разпространява хиляди безплатни SSL сертификати по автоматизиран начин. По този начин HTTPS се използва навсякъде - и катинарът в адресната лента на браузъра е престанал да служи като надежден индикатор за сигурност.

Производителите на DPI решения рекламират своите продукти от тези позиции. Те са вградени между крайните потребители (т.е. вашите служители, сърфиращи в мрежата) и интернет, като филтрират злонамерения трафик. Има редица такива продукти на пазара днес, но процесите са по същество едни и същи. HTTPS трафикът преминава през устройство за проверка, където се дешифрира и проверява за злонамерен софтуер.

След като проверката приключи, устройството създава нова SSL сесия с крайния клиент за дешифриране и повторно криптиране на съдържанието.

Как работи процесът на дешифриране/повторно криптиране

За да може устройството за проверка на SSL да дешифрира и повторно шифрова пакети, преди да ги изпрати до крайните потребители, то трябва да може да издава SSL сертификати в движение. Това означава, че трябва да има инсталиран CA сертификат.

За компанията (или който и да е по средата) е важно тези SSL сертификати да се доверяват на браузърите (т.е. да не задействат страшни предупредителни съобщения като това по-долу). Следователно CA веригата (или йерархията) трябва да бъде в довереното хранилище на браузъра. Тъй като тези сертификати не се издават от обществено доверени сертифициращи органи, трябва ръчно да разпределите йерархията на CA до всички крайни клиенти.

Предупредително съобщение за самоподписан сертификат в Chrome. източник: BadSSL.com

На компютри с Windows можете да използвате Active Directory и групови правила, но за мобилни устройства процедурата е по-сложна.

Ситуацията става още по-сложна, ако трябва да поддържате други основни сертификати в корпоративна среда, например от Microsoft или базирани на OpenSSL. Плюс защитата и управлението на частните ключове, така че някой от ключовете да не изтече неочаквано.

Най-добрият вариант: частен, специален основен сертификат от CA на трета страна

Ако управлението на множество корени или самоподписани сертификати не е привлекателно, има друга опция: разчитане на CA на трета страна. В този случай удостоверенията се издават от частни CA, който е свързан във верига на доверие със специален частен root CA, създаден специално за компанията.

Опростена архитектура за специални клиентски главни сертификати

Тази настройка елиминира някои от проблемите, споменати по-рано: поне намалява броя на корените, които трябва да се управляват. Тук можете да използвате само един частен основен орган за всички вътрешни PKI нужди, с произволен брой междинни CA. Например горната диаграма показва многостепенна йерархия, където един от междинните CA се използва за SSL проверка/декриптиране, а другият се използва за вътрешни компютри (лаптопи, сървъри, настолни компютри и т.н.).

При този дизайн не е необходимо да се хоства CA на всички клиенти, тъй като CA от най-високо ниво се хоства от 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 потребители се въздържаха.

Източник: www.habr.com