Самоподписан сертификат за VPN: какво означава и на какво се доверява
Самоподписаният сертификат за VPN все още криптира трафика. Променя се на кого сте казали да му се доверява, което хранилище получава това доверие и кои проверки остават.
Тук най-голяма вреда нанасят две вярвания: че самоподписан сертификат за VPN означава, че тунелът не е криптиран, и че инсталирането на каквото VPN клиентът поиска засяга само VPN. Нито едно от двете не издържа при сблъсък с реално внедряване. Самоподписаният сертификат описва връзка на подпис, а не присъда за сигурността, и обхватът на доверието, което добавяте, зависи от това в кое хранилище попада. Виждал съм бюро за помощ да импортира корен на доставчик в машина с Windows, за да заглуши едно предупреждение, а после да прекара следобеда в обяснения защо браузърът е спрял да се оплаква от несвързан портал. Двете половини на този въпрос принадлежат заедно, затова ги третирайте като едно.
Сертификатът не е хранилище за доверие
Файлът, който сървърът представя, носи публичен ключ, име на субект, име на издател, дати на валидност и разширения. Самоподписан означава, че субектът и издателят са едно и също образувание и подписът се проверява със собствения ключ на сертификата. Нищо в това определение не казва, че връзката е слаба, и нищо не казва, че клиентът ще го приеме.
Приемането идва от другаде: CA файл, към който насочвате клиента, отпечатък, който сравнявате на ръка, или корен, който вече стои в хранилище, което клиентът чете. Внедряването може да е напълно изправно, докато сертификатът му би се провалил на всеки публичен тест. openssl verify срещу системния пакет ще съобщи за неизвестен издател и това съобщение е вярно, а не дефект.
Опцията ca на OpenVPN е най-ясният случай на доверие, ограничено до приложението. Този файл именува котвите, които клиентът ще приеме, и може да съдържа един частен CA или, при малко внедряване, собствения самоподписан сертификат на сървъра. Версия 2.6 приема също --peer-fingerprint за заковаване на SHA-256 отпечатък вместо разпространяване на CA файл. WireGuard стои още по-навън: там няма никакви сертификати, само статичен публичен ключ за всеки партньор, така че въпросът за самоподписа не се отнася за него.
Къде инсталирате доверие решава кой ще го наследи
Поставете същия сертификат на три места и получавате три различни радиуса на поражение. Пакет, който чете само VPN клиентът, засяга този клиент. Корен в хранилището на операционната система засяга всяка програма, която се допитва до това хранилище. Браузър със собствена база за доверие може да игнорира и двете, затова предупреждение може да преживее импорт, който е изглеждал успешен.
В Debian или Ubuntu пускането на файл в /usr/local/share/ca-certificates/ и изпълняването на update-ca-certificates променят системния пакет. В Windows certutil -addstore -f Root пише в машинното хранилище и изисква повишен команден ред, докато добавянето на -user насочва към хранилището на текущия потребител; двете не са взаимозаменяеми. Firefox поддържа собствена база NSS, така че импорт на ниво ОС може никога да не се появи там.
Обхватът има значение заради това, което може да направи един издател. Издаващ CA може да подписва имена, с които няма връзка, така че всичко, което се доверява на това хранилище, ще приеме тези подписи. Един закован лист не може да направи това; той удостоверява точно една идентичност на партньор. Ако целта е един VPN да се свърже, CA, ограничен до приложението, или закован лист я постига, докато корен за цялата машина е много по-голяма отстъпка, отколкото изисква симптомът.
Все още криптирате без публичен CA
TLS ръкостискането извежда сесийни ключове независимо дали сертификатът на партньора се свързва към нещо, на което вече се доверявате. Самоподписан не означава чист текст и не означава, че трафикът е четим по време на пренос. Означава, че клиентът няма априорна причина да вярва, че ключът принадлежи на сървъра, който е поискал.
Именно в тази празнина живеят истинските атаки. Клиент, конфигуриран да приема всеки сертификат, било чрез изключена настройка за проверка, било чрез бутон „довери се все пак“, натиснат веднъж и забравен, ще криптира с удоволствие към когото и да отговори. Прихващането става на стъпката за удостоверяване, преди да се движат данните на приложението. Криптиране без проверка на идентичността държи пасивния наблюдател навън и прави малко друго.
Доверието към издателя не прескача проверката на името
Проверката на веригата, съпоставянето на име и предназначението на сертификата са отделни решения. Веригата може да е валидна, докато името е грешно, и името може да съвпада, докато сертификатът е издаден за друга роля. RFC 5280 дефинира полетата, които носят тези ограничения, а колко строго клиентът ги налага, е въпрос за всяко приложение.
OpenVPN прави разделението видимо. verify-x509-name заковава очаквания субект чрез съвпадение на name, name-prefix или subject. remote-cert-tls server изисква сертификатът на партньора да е използваем като сървърен сертификат, което отхвърля сертификат само за клиент дори когато издателят е доверен. Нито една от настройките не се заменя с доставяне на CA файл.
Прегледайте сертификата, преди да решите нещо:
openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltNameпоказва кой го е издал, за кои имена и до кога.openssl verify -CAfile ca.crt server.crtпроверява дали веригата, която планирате да доставите, наистина валидира листа.openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_errorработи за TLS крайни точки като уеб портал; протоколът OpenVPN на 1194 не е чист TLS поток, така че този тест не се прилага там.
Сертификат с изтекла дата, без subjectAltName за името, към което се свързвате, или с липсващо използване serverAuth се проваля независимо колко внимателно е инсталирана котвата.
Пет проверки, преди да приемете един
Сравнете отпечатъка по канал, който не е връзката, която се опитвате да поправите: конзола, инсталатор, който вече имате, подписан конфигурационен файл. openssl x509 -in server.crt -noout -fingerprint -sha256 на сървъра и същата стойност в журнала на клиента са достатъчни, за да знаете, че гледате един обект.
След това решете какво инсталирате: един лист или орган, който може да издава още. После решете къде отива и назовете приложенията, които четат това хранилище. Запишете пътя за премахване, докато още го помните, защото „довери се и продължи“ е начинът, по който временен импорт става постоянен.
Накрая планирайте промяната. Закован сертификат или отпечатък трябва да се обновява по същия доверен канал, когато сертификатът се сменя, а частният CA има свой собствен жизнен цикъл на издаване и оттегляне. Ако частният ключ изтече, повторното доверяване на копие от същия сертификат не поправя нищо; идентичността трябва да бъде заменена.
Ако предупреждение преживее и петте проверки, полезният въпрос не е кой бутон го заглушава, а кое хранилище клиентът всъщност чете и откъде е дошъл този корен. Отговорете на това и импортът, който ще направите, става решение, а не рефлекс.