Какво всъщност защитава паролата за частен ключ на 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 ключ с парола или отключено хранилище на мениджър за пароли. Тя повишава цената на кражбата на файла в покой и не прави нищо срещу зловреден софтуер, работещ като вашия потребител, оторизирано приложение, което иска от клиента да подпише, или администратор, който може да чете паметта. Третирайте я като един слой, а не като контролата, която прави ключа безопасен за оставяне наоколо.

Защо подканата продължава да се връща

Клиент, който пита отново при всяко повторно свързване, не е непременно повреден. Някои клиенти кешират паролата за сесията, други я съхраняват в ключодържателя на ОС, а трети могат да бъдат насочени към помощник, който я доставя, така че поведението зависи от клиента и неговата конфигурация, а не от файла с ключа.

Ако повтарящата се подкана е истинската оплакване, прегледайте опциите за кеширане и удостоверяване на клиента, преди да премахнете криптирането от ключа. Премахването на паролата превръща защитен файл в ключ с открит текст и повторното свързване става тихо на цената на единствения контрол в покой, който сте имали. По-добър отговор обикновено е поддържано хранилище за идентификационни данни със същите права върху файла, които иначе бихте използвали.

Загубата и излагането не са едно и също поправяне

Загубена парола не може да бъде възстановена от сертификата. Сертификатът е публичен материал, който свързва име с ключ; той не съдържа път обратно към частния ключ и никаква подсказка за паролата. Практическите варианти са оторизирано резервно копие на ключа или нова идентичност, издадена чрез нормалния процес на оператора. Всеки, който предлага да 'възстанови' паролата, предлага да я отгатне.

Излагането изисква различен отговор. Повторното криптиране на същия ключ с нова парола оставя ключовия материал непроменен, така че копие, което вече е било отключено другаде, все още работи. Поправката е да оттеглите или замените идентификационните данни: издайте нов ключ и сертификат, разпространете ги и изведете стария от употреба при партньора. Докато това не се случи, смяната на паролата на файла е домакинска работа, а не ограничаване. Дръжте стария файл извън резервните копия само след като новата идентичност бъде потвърдена като работеща, и запишете кой сериен номер или отпечатък я е заменил.