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

Зошто поканата постојано се враќа

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

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

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

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

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