La chiave è il percorso: perché Verimesh funziona su WireGuard

Molti di noi hanno passato più ore di quanto vorremmo ammettere a guardare persone che cercano di attivare un tunnel IPsec tra due firewall di vendor diversi. Chi ha vissuto le guerre VPN degli anni 2000 ricorda bene la sensazione: un file di configurazione con quaranta parametri, metà dei quali dovevano corrispondere esattamente all’altro lato, e un debug log che non ti diceva niente quando non combinavano.

Poi nel 2018 un singolo sviluppatore, Jason Donenfeld, ha sottoposto WireGuard per l’inclusione nel kernel Linux, e Linus Torvalds, qualcuno che notoriamente non ha peli sulla lingua, ha scritto che poteva “solo sperare” che venisse integrato presto, chiamandolo “un’opera d’arte” rispetto agli “orrori che sono OpenVPN e IPsec.” Questo è un grande elogio. È stato integrato nel mainline nel 2020.

Quindi quando Palo Alto Networks, che vende i pesanti appliance di sicurezza che WireGuard tranquillamente rende overbuilt, pubblica un explainer Cyberpedia elogiando la sua codebase ridotta, la crittografia moderna fissa e la velocità, vale la pena dedicarvi un momento.

La mesh crittografata sottostante Verimesh funziona su WireGuard, e facciamo una cosa sopra di essa che, per quanto ne so, nessun altro fa: la chiave del tunnel deriva dalla stessa radice dell’identità dell’applicazione.

Cosa Palo Alto sta approvando

WireGuard non risponde ai pacchetti che non può autenticare. Invia un probe da una chiave sconosciuta e non ottieni nulla: nessun banner, nessuna risposta, neanche un socket in ascolto da fingerprint. Per una scansione di porte la mesh semplicemente non esiste, e non puoi attaccare una superficie che non puoi trovare.

Poi c’è la dimensione. WireGuard è circa 4.000 righe di codice. OpenVPN è circa 100.000. IPsec, contando il suo insieme di standard e implementazioni, è più vicino a 400.000. Una codebase che puoi leggere in un pomeriggio è una che un essere umano può effettivamente audire. E l’auditabilità a quella scala è essa stessa una proprietà di sicurezza, una che non puoi retrofittare su qualcosa due ordini di grandezza più grande.

La crittografia è fissa. Nessun cipher suite configurabile, nessuna negoziazione di algoritmi, nessun passo “degradiamo a qualsiasi cosa entrambi supportiamo”. Solo Curve25519 per lo scambio di chiavi, ChaCha20-Poly1305 per i dati, BLAKE2s per l’hashing, Noise_IKpsk2 che tiene insieme il tutto. L’intera famiglia di attacchi di downgrade non esiste qui, perché non c’è niente da negoziare.

E WireGuard instrada per chiave. La sua tabella di routing crittografica per chiave associa la chiave pubblica di ogni peer agli intervalli IP che quel peer può utilizzare. In uscita, l’indirizzo di destinazione seleziona la chiave del peer, che seleziona la chiave di sessione; in entrata, un pacchetto decifrato viene accettato solo se la sua sorgente rientra nell’intervallo autorizzato di quel peer. Non c’è uno “chi sei” separato attaccato accanto a un “cosa puoi inviare” check. La chiave pubblica è il percorso. L’identità e la raggiungibilità si rivelano essere lo stesso fatto.

Una radice, non due

In quasi tutte le implementazioni di WireGuard che ho visto, le chiavi vivono una vita propria. Qualcuno esegue wg genkey, distribuisce la metà pubblica, archivia la metà privata da qualche parte, e finisce con una chiave di rete che non ha nulla a che fare con l’identità che l’applicazione sopra di essa si fida. Due radici di trust riconciliate da un foglio di calcolo e buone intenzioni.

In Verimesh c’è una radice. Le chiavi del tunnel Curve25519 di ogni organizzazione sono ancorate nel suo materiale DKMS (Decentralized Key Management). La stessa infrastruttura di identità su cui il layer dell’applicazione già funziona. Nessuno le emette. Non c’è alcuna autorità di certificazione nel percorso che decide quali tunnel sono consentiti, e nessun divario tra chi sei al layer di rete e chi sei sopra di esso.

Poiché le chiavi risalgono al materiale della chiave dell’organizzazione, ogni tunnel può essere verificato rispetto al key event log: puoi chiedere quale identità ha attivato quale tunnel e quando, e verificare la risposta crittograficamente piuttosto che fidarsi dell’account di un server su se stesso. Quando le chiavi ruotano, ruotano in sincronia con la pre-rotazione DKMS (costruita su KERI), quindi l’identità del tunnel sopravvive al ciclo di vita della chiave invece di rompersi quando una chiave cambia. E poiché il tutto è self-hosted, nessun intermediario siede nel mezzo possedendo il flusso di dati.

Allora perché non usare semplicemente mTLS, che già associa l’identità all’handshake del trasporto?

Perché mantenere i layer separati è il punto. WireGuard sposta pacchetti autenticati e cifrati tra peer che hanno la chiave giusta, e poi si ferma. Non sa cosa sia un ritiro del consenso, quale autorizzazione un messaggio porti, o se una credenziale sia stata revocata. Quella logica appartiene sopra il filo, in DKMS. mTLS tende a trascinare l’autorizzazione giù nell’handshake del trasporto finché non riesci più a audire i due separatamente. Li manteniamo separati di proposito, e li costruiamo sulla stessa radice.

Sovrano fino al filo

Lo stack è Open Source da cima a fondo. WireGuard è nel kernel; il layer DKMS sopra di esso è nostro, pubblicato sotto AGPLv3. Nessun control plane SaaS siede nel percorso. Nessuna terza parte che possa essere citata in giudizio per le chiavi, nessuno che tranquillamente registra chi ha parlato con chi. Per l’healthcare svizzero, dove i dati non possono lasciare il paese e la fiducia non può lasciare l’istituzione, questo deve valere fino al trasporto. Sovranità che si ferma al layer dell’applicazione e affitta la sua tubatura di rete a qualcun altro non è davvero sovranità.

Cosa stiamo scambiando

Nessuna architettura è gratuita, e le persone che gestiscono questi sistemi lo sentono quando pretendi il contrario. WireGuard chiede tre scambi, di cui siamo trasparenti:

Primo, è un tunnel layer-3. Trasporta pacchetti IP, non stream, quindi non ottieni il multiplexing nativo dei stream che un trasporto basato su TLS o QUIC ti fornisce gratuitamente. Qualsiasi cosa abbia bisogno di multiplexing lo costruisce sopra il tunnel. Per una mesh che trasporta scambi autenticati tra istituzioni questo è probabilmente il posto giusto, ma è un vero vincolo, non una non-issue.

Secondo, la superficie di configurazione dei peer cresce con la mesh. WireGuard non ha un control plane che distribuisce e revoca i peer centralmente; ogni nodo conosce i peer con cui comunica. In una piccola mesh governata di hub e nodi questo è una feature. Niente di centrale da compromettere. A larga scala diventa un vero lavoro, e amministrare le chiavi via DKMS è quello che la impedisce di collassare nell’incubo del foglio di calcolo da prima.

Terzo, è più giovane di IPsec. Palo Alto mette questo nella lista dei contro e ha senso. Ma la cosa che rende WireGuard giovane è la stessa cosa che la rende auditabile: Donenfeld ha buttato via tre decadi di optionalità accumulata e ha ricominciato da capo. Questo è il tipo di scambio che facciamo volentieri.

La questione quantica

WireGuard ha un layer di chiave pre-condivisa opzionale che mescola un segreto simmetrico nell’handshake. Questo acquista una cosa: il traffico catturato oggi non diventa leggibile più tardi anche se lo scambio di curve ellittiche viene eventualmente rotto. L’attacco store-now-decrypt-later smette di funzionare. Questo non è lo stesso della sicurezza post-quantica nel senso NIST, e siamo consapevoli di questo. È una copertura efficace.

Il percorso oltre la copertura ha un nome: Rosenpass, un progetto Open Source che esegue un autentico scambio di chiavi post-quantico davanti a quello slot di chiave pre-condivisa. È un percorso di integrazione per la mesh, non qualcosa che Verimesh spedisce oggi.

Quello che è nostro è quello che succede dopo. Poiché le chiavi del tunnel derivano da DKMS, adottare algoritmi post-quantici è una routine key rotation sul key event log esistente. Non un’emissione di certificati forzata, all’unisono in tutta un’intera proprietà. Transport emesso da CA non può dirlo.

Una radice, dal filo in su

Una mesh dove la chiave di rete e l’identità dell’applicazione crescono dallo stesso materiale DKMS chiude la cucitura dove vivono la maggior parte degli attacchi interessanti e quasi tutti i noiosi fallimenti di audit: il divario tra chi la rete pensa che tu sia e chi l’applicazione pensa che tu sia. WireGuard ci fornisce un trasporto semplice abbastanza per fidarsi; DKMS gli dà la stessa identità di cui tutto il resto in Verimesh già si fida.

Questo è il trasporto sotto il rollout di Verimesh con HIN, sotto tutto nell’Architettura di fiducia, dove il percorso completo da chiave a tunnel a messaggio auditato è esposto end to end. Quello che funziona sopra è Verimesh stesso.

La buona tubatura è il tipo di cui non devi mai pensare. Questa è l’idea intera.