Шта заправо штити лозинка на приватном кључу 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 кључа са лозинком или откључаног трезора менаџера лозинки. Подиже цену крађе датотеке у мировању и не чини ништа против злонамерног софтвера који ради као ваш корисник, овлашћене апликације која тражи од клијента да потпише, или администратора који може да чита меморију. Третирајте то као један слој, а не као контролу која кључ чини безбедним за остављање унаоколо.

Зашто се упит стално враћа

Клијент који поново пита при сваком поновном повезивању није нужно покварен. Неки клијенти кеширају лозинку за сесију, неки је чувају у привеску кључева ОС-а, а неки се могу усмерити на помоћника који је доставља, па понашање зависи од клијента и његове конфигурације, а не од датотеке кључа.

Ако је поновљени упит стварна жалба, прегледајте опције кеширања и аутентификације клијента пре него што уклоните шифровање са кључа. Уклањање лозинке претвара заштићену датотеку у кључ отвореног текста, а поновно повезивање постаје тихо по цени једине контроле у мировању коју сте имали. Бољи одговор обично је подржано складиште акредитива са истим дозволама датотеке које бисте ионако користили.

Губитак и излагање нису иста поправка

Изгубљена лозинка не може се опоравити из сертификата. Сертификат је јавни материјал који везује име за кључ; не садржи пут назад до приватног кључа ни наговештај о лозинки. Практичне опције су овлашћена резервна копија кључа или нови идентитет издат кроз уобичајени процес оператера. Свако ко нуди да 'опорави' лозинку нуди да је погоди.

Излагање захтева другачији одговор. Поновно шифровање истог кључа новом лозинком оставља материјал кључа непромењен, па копија која је већ била откључана негде другде још ради. Поправка је опозвати или заменити акредитив: издати нови кључ и сертификат, дистрибуирати их и повући стари код партнера. Док се то не догоди, промена лозинке датотеке је кућно одржавање, а не обуздавање. Држите стару датотеку изван резервних копија тек након што се потврди да нови идентитет ради, и забележите који је серијски број или отисак заменио.