Ключът е маршрутът: Защо Verimesh работи на WireGuard
Мнозина от нас сме прекарали повече часа, отколкото бихме желали, гледайки хора, които се опитват да поднесат IPsec тунел между два firewall-а от различни производители. Всеки, който е преживял VPN войните на 2000-те години, помни чувството: конфигурационен файл с четиридесет параметъра, половината от които трябва да съвпадат точно с другата страна, и debug лог, който ти казва нищо, когато не се съвпадат.
През 2018 г. един разработчик, Jason Donenfeld, представи WireGuard за включване в Linux kernel, а Linus Torvalds, известен със своята директна реч, написа, че може само да “надява се” да бъде слят скоро, наричайки го “произведение на изкуството” в сравнение с “ужасите на OpenVPN и IPSec”. Това е висока похвала. Той влезе в mainline през 2020 г.
Така че, когато Palo Alto Networks, която продава тежките security приложения, които WireGuard тихо прави да изглеждат преразмерени, публикува Cyberpedia обяснител, хвалещ малката й кодова база, фиксирана модерна криптография и скорост, това си струва да обърнем внимание.
Криптирана mesh мрежа под Verimesh работи на WireGuard, и правим едно нещо върху нея, което, доколкото знам, никой друг не прави: ключът на тунела се извлича от същия корен като идентичността на приложението.
Какво Palo Alto одобрява
WireGuard не отговаря на пакети, които не може да удостовери. Изпрати проба от неизвестен ключ и не получаваш нищо: без banner, без отговор, дори без listening socket за идентификация. За port scan мрежата просто няма там, и не можеш да нападаш повърхност, която не можеш да намериш.
След това има размерът на кода. WireGuard е приблизително 4 000 реда код. OpenVPN е около 100 000. IPsec, считайки разпространението на стандартите и имплементациите, е по-близо до 400 000. Кодова база, която можеш да прочетеш в един следобед, е такава, която човек всъщност може да одити. И одитируемост в такъв мащаб е сама по себе си свойство на сигурност, което не можеш да придобиеш задним числом върху нещо два порядъка по-голямо.
Криптографията е фиксирана. Никакви конфигурируеми cipher suites, никакво negotiation на алгоритъма, никакъв “нека да се снижим до което и да е двете да поддържаме” етап. Просто Curve25519 за key exchange, ChaCha20-Poly1305 за данните, BLAKE2s за хеширането, Noise_IKpsk2 като свързващо звено. Целото семейство на downgrade атаки не съществува тук, защото няма нищо за negotiate.
И WireGuard маршрутизира по ключ. Неговата cryptokey routing таблица свързва публичния ключ на всеки peer с IP обхватите, които този peer може да използва. Outbound, адресът на назначението избира ключа на peer-а, който избира session ключа; inbound, пакет се приема само ако неговия източник попада в авторизирания обхват на този peer. Няма отделна “кой си ти” проверка прикрепена до “какво можеш да изпратиш” проверка. Публичният ключ е маршрутът. Идентичност и достъпност се оказват същия факт.
Един корен, не два
В почти всяко WireGuard внедряване, което съм видял, ключовете живеят собствен живот. Някой изпълнява wg genkey, раздава публичната половина, архивира частната половина някъде, и завършва с мрежов ключ, който няма нищо общо с идентичността, която приложението над него доверява. Два корена на доверие примирени чрез електронна таблица и добри намерения.
В Verimesh има един корен, и всичко се окачва от него. Всяка организация има собствена идентичност, построена на Decentralized Key Management (DKMS) — същата инфраструктура на идентичност, която слоят на приложението вече работи. Под тази организационна идентичност, всяко свързване се поднася от Iris Agent, който притежава собствена agentic идентичност: верифицируем актив, вкоренен в DKMS материала на организацията, който стои за един възел в mesh мрежата вместо за институцията като цяло. Curve25519 тунелните ключове се извличат от тази agentic идентичност — не от низ, който някой генерира веднъж с wg genkey и залепи в конфигурация. Няма трета страна certificate authority в пътя, решавайки кои тунели са разрешени; организацията издава собствените си agentic идентичности, под собствения си корен. Никакъв пропуск между това кой си ти на мрежовия слой и кой си ти над него.
Този междинен слой не е церемониял. Това е това, което прави мрежата практична. Организация може да поднесе повече от един възел — отделни сайтове, отделни data центрове, двата края на клиничен консорциум — всеки със собствена agentic идентичност под същия организационен корен, всеки от тях верифицируемо същата институция. И мрежата може да се движи по собствения си часовник: когато тунелният ключ трябва да се промени, ротираш agentic идентичността, от която се извлича, без да докосваш организационната идентичност или ключовете на приложението над нея. Проводът може да се вълнува отдолу, докато идентичността на институцията остава точно там, където е.
Тъй като всяка agentic идентичност се връща към ключовия материал на организацията, всеки тунел може да бъде проверен срещу key event лога: можеш да запиташ коя идентичност поднесе кой тунел и кога, и да верифицираш отговора криптографски вместо да доверяваш сметката на самия сървър. Когато ключовете се ротират, те се ротират в съответствие с DKMS пред-ротацията (построена на KERI), така че тунелната идентичност оцелява жизненния цикъл на ключа вместо да се скъсва, когато ключ се промени. И тъй като цялото нещо е self-hosted, никой посредник не седи в средата, като притежава потока от данни.
Така че защо не просто да използваме mTLS, който вече свързва идентичност в транспортния handshake?
Защото държането на слоите отделно е смисълът. WireGuard преместват удостоверени, криптирани пакети между peer-и, които притежават правилния ключ, и тогава спира. Той не знае какво е отказ на съгласие, коя авторизация носи съобщение, или дали креденциал е отозван. Такава логика принадлежи над проводът, в DKMS. mTLS има тенденция да привлече авторизация надолу в транспортния handshake, докато вече не можеш да одитираш двата отделно. Держим ги отделно умишлено, и ги изграждаме на същия корен.
Суверенен до проводът
Стекът е Open Source от горе до долу. WireGuard е в kernel; DKMS слоят над него е нашият, публикуван под AGPLv3. Никакъв SaaS control plane не седи в пътя. Никоя трета страна, която може да бъде потеглена за ключовете, никой тихо логирайки кой говори с кого. За швейцарската здравеопазване, където данните не могат да напуснат страната и доверието не може да напусне институцията, това трябва да задържи до транспорта. Суверенност, която спира на слоя на приложението и наема си мрежовите тръбопроводи от някой друг, не е наистина суверенност.
Какво отказваме
Никоя архитектура не е безплатна, и хората, които управляват тези системи, могат да го почувстват, когато преструвате противното. WireGuard поставя три компромиса, за които сме прозрачни:
Първо, това е layer-3 тунел. Той носи IP пакети, не потоци, така че не получаваш родното stream multiplexing, който TLS- или QUIC-базиран транспорт ти предлага безплатно. Всичко, което трябва multiplexing, го построява над тунела. За мрежа, носеща удостоверен обмен между институции, това е спорително правилното място за него, но это е реално ограничение, не non-issue.
Второ, повърхността на конфигурация на peer расте с мрежата. WireGuard не доставя control plane, който раздава и отозива peer-и централно; всеки възел знае peer-ите, с които говори. В малка, управлявана мрежа от hub-ове и възли, това е feature. Нищо централно за компрометиране. На голем мащаб то става истинска работа, и администриране на ключовете чрез DKMS е това, което го пречи да се сруши в nightmare на електронна таблица от по-рано.
Трето, то е по-младо от IPsec. Palo Alto слага това в cons списък и има смисъл. Но нещото, което прави WireGuard младо, е същото нещо, което го прави одитируем: Donenfeld хвърли три десетилетия натрупана по доброволност и започна наново. Това е вид компромис, който правим с радост.
Квантовия въпрос
WireGuard има опционален pre-shared-key слой, който смесва симетрична тайна в handshake. Това купува едно нещо: трафик, уловен днес, не става четлив по-късно, дори ако elliptic-curve exchange евентуално се счупи. Store-now-decrypt-later атаката спира да работи. Това не е същото като post-quantum сигурност в NIST смисъл, и ние сме осведомени за това. Това е ефективна хеджира.
Маршрутът мимо хеджирането има име: Rosenpass, Open Source проект, който изпълнява истински post-quantum key exchange пред този pre-shared-key слот. Това е integration път за мрежата, не нещо което Verimesh доставя днес.
Това, което е наше, е каквото идва след. Защото тунелните ключове се извличат от DKMS идентичност, приемане на post-quantum алгоритми е routine ротация на тази идентичност на съществуващия key event лог — мрежовия слой движейки се по собствения си часовник отново, този път към по-силен алгоритъм. Не принудена, all-at-once certificate преиздаване на целия имот. CA-издадения транспорт не достига да каже това.
Един корен, от проводът нагоре
Мрежа, където мрежовия ключ и идентичност на приложението растат от същия DKMS материал, затваря шева, където живеят най-интересните атаки и почти всички скучни audit провали: пропуска между кой мрежата мисли, че си, и кой приложението мисли, че си. WireGuard ни дава транспорт простичък да му се доверим; DKMS му дава същата идентичност всичко останало в Verimesh вече доверява.
Това е транспортът под Verimesh внедрението с HIN, под всичко в Trust Architecture, където пълният път от ключ до тунел до одиран съобщение е направен край до край. Какво работи отгоре е Verimesh сам.
Добрите тръбопроводи са вида, за които никога не трябва да мислиш. Това е целия идеи.
