0x o 0s? Decifrare il formato PSK in ipsec.secrets

Un client si autentica con la chiave condivisa e un altro la rifiuta, eppure i caratteri incollati sembrano identici su entrambi i lati. Probabilmente sono gli stessi caratteri; la differenza sta in quale regola di decodifica il file applica loro. Una stringa tra virgolette viene presa alla lettera, un token che inizia con 0x viene letto come esadecimale, e un token che inizia con 0s viene letto come Base64. Solo una di queste tre grafie significa ciò che intendevate, quindi la correzione è di solito una conversione e non una password migliore.

Il sintomo punta alla codifica, non ai cifrari

Quando le due estremità tengono byte diversi, la negoziazione riesce comunque e la prova fallisce dopo. Il registro segnala allora un guasto di integrità o HMAC invece di una discrepanza di algoritmo, perché è stata scelta una proposta e il passo di autenticazione non ha corrisposto. Quella riga non menziona mai la forma del segreto.

La fase è l’indizio. Un guasto che arriva dopo una proposta scelta significa che entrambe le parti hanno concordato tutto tranne il materiale di chiave, mentre «nessuna proposta scelta» appartiene alla policy o alle suite di cifratura. Un controllo di integrità che fallisce mentre la password sembra corretta è il volto visibile di una discrepanza di codifica.

Un segreto, tre modi in cui il file può leggerlo

Per il valore di quattro byte key1, l’esadecimale e il Base64 sono due ricodifiche degli stessi byte, e solo i caratteri iniziali dicono al parser quale dei due sta tenendo. Le credenziali di swanctl seguono la stessa convenzione, quindi un valore spostato tra le due interfacce conserva il significato solo se il suo prefisso viaggia con esso.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

Due dettagli di quel blocco costano più tempo. Le cifre esadecimali accettano entrambi i casi, quindi 0x6b657931 e 0x6B657931 sono lo stesso valore, ma un numero dispari di caratteri viene letto male in silenzio invece di essere rifiutato, il che sposta ogni byte dopo il taglio. Il riempimento Base64 fa parte del valore, quindi una stringa incollata senza i suoi segni = finali si decodifica in byte diversi invece di fallire rumorosamente.

Un profilo che ha decodificato il valore una volta lo ha già convertito, quindi decodificarlo di nuovo produce byte diversi e un guasto di autenticazione che si legge come una password sbagliata. Le virgolette sono la direzione sicura per tutto ciò che è ambiguo, perché il contenuto è letterale anche quando inizia con un marcatore di codifica.

Da dove viene il testo Base64

Le esportazioni dei profili e i portali dei fornitori consegnano spesso la chiave già codificata, di solito in un campo dati che non è mai stato pensato per essere digitato a mano. O si scarta quel valore e si conserva il testo decodificato tra virgolette, oppure lo si lascia codificato con il marcatore davanti. Fare metà di ciascuno è ciò che rompe. Entrambe le strade funzionano solo se il valore intero sopravvive alla copia.

Entrambe le direzioni sono un comando ciascuna, e vale la pena tenerle nel ticket come l’operazione esatta che ha prodotto il valore memorizzato. Eseguitele in questo ordine:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

Incollare testo codificato come se fosse semplice è l’errore costoso. Il file calcola l’hash dei caratteri esattamente come sono scritti, la chiave derivata esce circa un terzo più lunga di quella calcolata dal pari, e ogni tentativo fallisce allo stesso modo senza avviso, perché il parser ha seguito la regola che gli è stata data.

Verificate quali byte usa davvero ciascun pari

Leggete prima la visione del demone sulla connessione e poi il risultato dell’autenticazione, invece di indovinare una causa dalla stringa di errore. Confrontare la lunghezza memorizzata è un rapido controllo di buon senso, perché il testo codificato è più lungo dei byte che rappresenta. Poi verificate quale riga di identità ha corrisposto, perché un segreto corretto archiviato sotto il pari sbagliato fallisce esattamente come uno sbagliato. L’ordine delle righe lo decide: la prima corrispondenza vince, quindi una riga ampia %any vicino in alto sostituisce in silenzio la riga specifica che avete appena modificato.

Ricaricare invece di riavviare quando il file è corretto. ipsec rereadsecrets aggiorna la copia del demone IKE, e un’installazione swanctl carica le credenziali con il proprio comando. Un riavvio scarta ogni associazione stabilita e distrugge il confronto che stavate cercando di fare.

Nessuno di questi controlli richiede di esporre il segreto. Una lunghezza, un selettore di identità e una posizione di riga spiegano la maggior parte di questi guasti prima che qualcuno abbia bisogno di un dump esadecimale.

Modificate il file senza nascondere il risultato

Limitate il file all’account del demone e tenete i segreti attivi fuori da ticket, chat e schermate, perché una chiave incollata è una fuga e non una diagnosi. Sopravvive anche all’incidente che l’ha prodotta.

Provate da un client di cui controllate la configurazione, confermate che l’autenticazione riesce, poi confermate che il tunnel trasporta traffico. Una ricarica che sistema la stretta di mano mentre l’instradamento resta rotto è un altro problema, e diventa visibile appena il segreto smette di muoversi.