OpenVPN без CA: как peer-fingerprint проверява партньорите

Малко внедряване посяга към отпечатъци, защото сертификатният орган прилича на инфраструктура, за която никой няма време да се грижи. Инстинктът е разумен, а краткият път, който хората вместо това поемат — копиране на една тайна на канала за данни към двата края — не е. Настройката peer-fingerprint запазва структурата на TLS непокътната: всяка страна все още държи своя частен ключ и сертификат и всяка страна все още проверява другата. Променя се къде е закотвена проверката: от доверен издател към кратък списък от заковани дайджести. Тъй като дайджестът покрива целия сертификат, а не име, подновяването се превръща в операцията, която наистина отнема време.

Към какво всъщност се ангажира отпечатъкът

Отпечатъкът на сертификат е дайджест на целия сертификат в DER кодиране, а не на публичния му ключ и не на името на субекта му. Затова два сертификата с еднакви имена и същия ключ, но различни дати на валидност имат различни отпечатъци. Именно това прави заковаването точно, а също и прави подновяването разрушително. Заковаването не може да означава доверие на ключ по принцип, защото то назовава един артефакт в един момент от живота му. Всеки може да знае дайджеста и знанието му само по себе си не доказва нищо.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

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

Картата е реципрочна, не симетрична

Всеки край се нуждае от две неща: своя частен ключ заедно със сертификата и изявление кои сертификати на партньори ще приема. При клиента това изявление е дайджестът на сертификата на сървъра; при сървъра то е списъкът с дайджести на регистрираните клиенти. Официален пример за малка настройка за Community 2.6 показва подредбата с peer-fingerprint и си струва да се прочете, преди да изберете този модел на доверие за реално внедряване. Двете посоки не са един обърнат списък и те не се провалят в един и същ момент.

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

Регистрация: как се присъединява ново устройство

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

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

Подновяването е скъпият момент

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

Планирайте реда преди датата на изтичане, а не след нея. Разпределете новия дайджест към страните, които го проверяват, приложете промяната и едва след това сменете сертификата на края. Този ред не оставя прозорец, в който двете страни да не са съгласни кой сертификат е актуален. Дръжте и самия списък под преглед, защото закован списък натрупва записи за устройства, изведени от употреба преди месеци. Всеки остарял запис е самоличност, която все още се удостоверява, ако ключът ѝ оцелее, затова премахването на един е действие по сигурността, а не домакинска работа.

Какво не решава картата на доверието

Удостоверяването е един слой и закованата карта не казва нищо за пула от адреси, изтласкваните маршрути, MTU на пътя или политиката на защитната стена. Те остават отделна конфигурация с отделни режими на отказ. Тунел, който се удостоверява и не пропуска трафик, е различно разследване от такъв, който никога не се вдига.

Картата също не се мащабира безкрайно и PKI, базирана на издател, е мястото, където стигат по-големите внедрявания. Това предпочитание е за операциите, а не за криптографията, тъй като добавянето и оттеглянето на самоличности през един орган е по-евтино от редактиране на списък при всеки партньор, докато флотата расте. Когато клиентска реализация не поддържа опцията, отговорът е съвместим модел на доверие, който този клиент документира, или поддържана замяна. Потискането на предупреждението за проверка не добавя тази поддръжка и цялата стойност на дизайна е, че проверката все още се случва.