Што насамрэч абараняе парольная фраза на прыватным ключы VPN

Запыт, які з'яўляецца пры запуску кліента VPN, лёгка прачытаць няправільна. Гэта не пароль уліковага запісу VPN, гэта не пароль для тунеля, і яго ўвод не даказвае, што злучэнне бяспечнае. Ён разблакіроўвае адно захаванае прадстаўленне прыватнага ключа, каб кліент мог прачытаць матэрыял ключа і выкарыстаць яго для аўтэнтыфікацыі. Усё, што адбываецца пасля гэтага, — іншае пытанне.

На практыцы адказ ламаецца на краях: людзі мяркуюць, што парольная фраза абараняе працуючы тунель, або што яе змена адклікае копію ключа, якая ўжо ўцякла. Абодва меркаванні няправільныя, і абодва няправільныя так, што пасведчанне застаецца адкрытым, пакуль аператар лічыць, што з ім разабраліся.

Адзін дыялог, некалькі розных сакрэтаў

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

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

Што ахоплівае шыфраванне на дыску

Шыфраваны ключ PEM бывае двух формаў, і загаловак паказвае, якая ў вас. Сучасная форма PKCS#8 пачынаецца з -----BEGIN ENCRYPTED PRIVATE KEY-----; старая форма PEM, якая ўсё яшчэ часта сустракаецца ў старых наладах OpenVPN, пачынаецца з -----BEGIN RSA PRIVATE KEY----- і змяшчае Proc-Type: 4,ENCRYPTED і радок DEK-Info адразу пад ім. Файл захоўвае прыватны ключ шыфраваным пад ключом, вытворным ад вашай парольнай фразы, звычайна праз KDF на аснове пароля з указанай колькасцю ітэрацый або каэфіцыентам працы. Дакументацыя OpenSSL pkey апісвае фарматы і параметры парольнай фразы, якія прымяняюцца пры чытанні.

Адсюль вынікаюць дзве наступствы. Слабую парольную фразу можна атакаваць па-за сеткай з хуткасцю, якую дазваляе KDF, таму правы на файл і доступ да рэзервовых копій усё яшчэ важныя, нават калі файл шыфраваны. А нападнік, які атрымаў толькі файл без парольнай фразы, вымушаны ўгадваць; той, хто атрымаў файл і парольную фразу, мае ключ, нібыта ён ніколі не быў шыфраваны.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 паказвае загаловак, а ў старым файле — радкі Proc-Type і DEK-Info, якія даказваюць шыфраванне; адзін радок сам па сабе не з'яўляецца доказам ні ў адзін бок. Радок pkey запытвае парольную фразу і друкуе толькі публічную палову, што даказвае, што файл і парольная фраза працуюць без раскрыцця прыватнага ключа. Не выкарыстоўвайце -text для гэтай праверкі: ён друкуе прыватныя кампаненты, privateExponent, prime1, prime2 і астатняе, і гэты вывад ніколі нельга ўстаўляць нікуды — ні ў тыкет, ні ў чат, ні ў журнал. Каманда PKCS#12 таксама паведамляе, ці мае пакет асобны пароль MAC або шыфравання, што варта ведаць, перш чым перадаць яго калегу.

Што ён перастае абараняць пасля загрузкі ключа

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

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

Чаму запыт увесь час вяртаецца

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

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

Страта і раскрыццё — не адно і тое ж рамантаванне

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

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