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