Раней сертыфікаты часта заканчваліся з-за таго, што іх трэба было абнаўляць уручную. Людзі проста забывалі гэта зрабіць. З з'яўленнем Let’s Encrypt і аўтаматычнай працэдуры абнаўлення быццам бы праблема павінна быць вырашана. Але нядаўняя гісторыя з Firefox паказвае, што насамрэч яна па-ранейшаму актуальная. На жаль, сертыфікаты працягваюць заканчвацца.

Калі нехта прапусціў гэтую гісторыю, апоўначы 4 мая 2019 года раптам спынілі працаваць амаль усе пашырэнні Firefox.

Як высветлілася, масавы збой узнік з-за таго, што ў Mozilla скончыўся тэрмін дзеяння сертыфіката, які выкарыстоўваўся для подпісы пашырэнняў. Таму яны адзначаліся як "невалідныя" і не праходзілі праверку (тэхнічныя дэталі). На форумах у якасці абыходнага шляху рэкамендавалі адключыць праверку подпісаў пашырэнняў у about: config ці пераводам сістэмных гадзін.

Mozilla аператыўна выпусціла патч Firefox 66.0.4, які вырашае праблему з невалідным сертыфікатам, а ўсе пашырэнні вяртаюцца ў нармальны выгляд. Распрацоўнікі рэкамендуюць усталяваць яго і не выкарыстоўваць ніякія абыходныя шляхі для абыходу праверкі подпісаў, таму што яны могуць канфліктаваць з патчам.

Тым не менш, гэтая гісторыя яшчэ раз паказвае, што заканчэнне тэрміна дзеяння сертыфікатаў застаецца актуальнай праблемай і сёння.

У сувязі з гэтым цікава паглядзець на даволі арыгінальны спосаб, як з гэтай задачай справіліся распрацоўшчыкі пратакола. DNSCrypt. Іх рашэнне можна падзяліць на дзве часткі. Па-першае, гэта кароткатэрміновыя сертыфікаты. Па-другое папярэджанне карыстальнікаў аб заканчэнні тэрміну дзеяння доўгатэрміновых.

DNSCrypt

DNSCrypt – пратакол шыфравання DNS-трафіку. Ён абараняе DNS-камунікацыі ад перахопаў і MiTM, а таксама дазваляе абыйсці блакіроўкі на ўзроўні DNS-запытаў.

Пратакол абарочвае DNS-трафік паміж кліентам і серверам у крыптаграфічную канструкцыю, працуючы па транспартных пратаколах UDP і TCP. Каб яго выкарыстоўваць, і кліент, і DNS-рэзалвер павінны падтрымліваць DNSCrypt. Напрыклад, з сакавіка 2016 года яго ўключыў на сваіх DNS-серверах і ў браўзэры "Яндэкс". Аб падтрымцы абвясцілі і некаторыя іншыя правайдэры, у тым ліку Google і Cloudflare. Нажаль, іх не так шмат (на афіцыйным сайце пералічана 152 публічных DNS-сервера). Але праграму dnscrypt-proxy можна ўсталяваць уручную на кліентах пад Linux, Windows і MacOS. Ёсць і серверныя імплементацыі.

Як працуе DNSCrypt? Калі сцісла, то кліент бярэ публічны ключ абранага правайдэра і з яго дапамогай правярае яго сертыфікаты. Ужо там знаходзяцца кароткатэрміновыя публічныя ключы для сэсіі і ідэнтыфікатар набору шыфраў. Кліентам рэкамендуецца генераваць новы ключ для кожнага запыту, а серверам - мяняць ключы. кожныя 24 гадзіны. Пры абмене ключамі прымяняецца алгарытм X25519, для подпісу - EdDSA, для блокавага шыфравання - XSalsa20-Poly1305 або XChaCha20-Poly1305.

Адзін з распрацоўшчыкаў пратакола Фрэнк Дзяніс піша, Што аўтаматычная замена кожныя 24 гадзіны вырашыла праблему пратэрмінаваных сертыфікатаў. У прынцыпе, эталонны кліент dnscrypt-proxy прымае сертыфікаты з любым тэрмінам дзеяння, але выдае папярэджанне "Перыяд dnscrypt-proxy ключоў для гэтага сервера занадта вялікі", калі ён сапраўдны больш за 24 гадзіны. Адначасова быў выпушчаны выява Docker, у якім рэалізавалі хуткую змену ключоў (і сертыфікатаў).

Па-першае, гэта надзвычай карысна для бяспекі: калі сервер скампраметаваны ці ключ качаў, то ўчорашні трафік не можа быць расшыфраваны. Ключ ужо змяніўся. Верагодна, гэта складзе праблему для выканання "закону Яравай", які змушае правайдэраў захоўваць увесь трафік, у тым ліку зашыфраваны. Разумеецца, што пазней яго можна будзе расшыфраваць пры неабходнасці, запытаўшы ключ у сайта. Але ў дадзеным выпадку сайт проста не зможа яго падаць, таму што выкарыстоўвае кароткачасовыя ключы, выдаляючы старыя.

Але галоўнае, піша Дзяніс, кароткатэрміновыя ключы прымушаюць серверы з першага дня наладзіць аўтаматызацыю. Калі сервер падключаецца да сеткі, а скрыпты змены ключоў не настроены ці не працуюць, гэта будзе неадкладна выяўлена.

Калі аўтаматызацыя мяняе ключы раз у некалькі гадоў, на яе нельга разлічваць, а людзі могуць забыцца пра заканчэнне тэрміну дзеяння сертыфіката. Пры штодзённай змене ключоў гэта будзе выяўлена імгненна.

У той жа час, калі аўтаматызацыя настроена нармальна, то не мае значэння, як часта праводзіцца змена ключоў: кожны год, кожны квартал ці тры разы на дзень. Калі ўсё працуе больш за 24 гадзіны, то будзе працаваць вечна, піша Фрэнк Дзяніс. Паводле яго слоў, рэкамендацыя штосутачнай змены ключоў у другой версіі пратакола разам з гатовай выявай Docker, якія рэалізуюць гэта, эфектыўна паменшыла колькасць сервераў са скончанымі сертыфікатамі, адначасова палепшыўшы бяспеку.

Аднак некаторыя правайдэры ўсё ж вырашылі па нейкіх тэхнічных прычынах устанавіць тэрмін дзеяння сертыфіката больш за 24 гадзіны. Гэтую праблему ў асноўным вырашылі з дапамогай некалькіх радкоў кода ў dnscrypt-proxy: карыстачы атрымліваюць інфармацыйнае папярэджанне за 30 дзён да заканчэння тэрміна дзеяння сертыфіката, іншае паведамленне з больш высокім узроўнем сур'ёзнасці за 7 дзён да заканчэння тэрміна дзеяння і крытычнае паведамленне, калі ў сертыфіката засталося менш за 24 гадзін. Гэта адносіцца толькі да сертыфікатаў, якія першапачаткова маюць працяглы тэрмін дзеяння.

Такія паведамленні даюць карыстальнікам магчымасць паведаміць аператарам DNS аб маючым адбыцца заканчэнні тэрміну дзеяння сертыфіката, пакуль не стала занадта позна.

Магчыма, калі б усе карыстачы Firefox атрымалі такое паведамленне, то ўжо хто-небудзь напэўна паведаміў распрацоўнікам і тыя б не дапусцілі заканчэнні тэрміна дзеяння сертыфіката. "Я не памятаю ні аднаго DNSCrypt-сервера са спісу агульнадаступных DNS-сервераў, у якіх скончыўся тэрмін дзеяння сертыфіката за апошнія два ці тры гады", – піша Фрэнк Дзяніс. У любым выпадку, мусіць, лепш спачатку папярэджваць карыстачоў, а не адключаць пашырэнні без папярэджання.

Крыніца: habr.com