Errore di autenticazione HMAC del pacchetto OpenVPN: quale livello?

Due errori vengono segnalati con lo stesso vocabolario e non hanno quasi nulla in comune. Uno è un pacchetto il cui tag di autenticazione non è stato verificato; l’altro è una persona le cui credenziali sono state rifiutate. Trattare il primo come il secondo vi manda a cercare una password che non è mai stata il problema.

Il messaggio nomina un livello, e il lavoro utile è decidere quale prima di sostituire qualsiasi materiale. Confrontare i candidati fianco a fianco è il modo più rapido per vedere la differenza.

Due errori che condividono una parola

Un errore di autenticazione del pacchetto nasce durante l’elaborazione del traffico: un tag o un digest su un pacchetto ricevuto non corrispondeva a ciò che il ricevente aveva calcolato. Un rifiuto dell’account avviene dopo che uno scambio di accesso è stato analizzato, e nomina un utente anziché un pacchetto. Un terzo messaggio, sull’impossibilità di trovare un HMAC in un pacchetto in arrivo, è ancora diverso, perché lì il pacchetto è arrivato del tutto senza l’elemento di autenticazione atteso. Il prefisso completo del log vi dice quale dei tre avete, e il prefisso è di solito la prima cosa che viene rimossa quando un errore viene incollato in un ticket.

La distinzione cambia la riparazione. Una richiede impostazioni di canale corrispondenti, l’altra lo stato dell’account, e la terza un profilo che non corrisponde all’ascoltatore raggiunto.

Confrontate che cosa ha caricato davvero il processo in esecuzione

Un file corretto sul disco non dimostra nulla su un processo avviato prima della sua modifica. Controllate il profilo selezionato, l’endpoint contattato e se il servizio è stato ricaricato dopo la modifica. Confermate anche che l’endpoint appartenga al profilo, perché un’altra istanza o un altro servizio può essere in ascolto dove il vecchio file si aspetta altro.

Riesportare un profilo supportato dalla stessa fonte è un confronto economico, perché elimina la deriva tra ciò che credete configurato e ciò che il client invia davvero. Generare nuovo materiale di chiave è un passo molto più grande, e aiuta solo se entrambe le estremità lo adottano insieme. Sostituire un lato localmente ricrea la discrepanza che stavate cercando di rimuovere.

Confrontate il canale di controllo con il canale dati

Due meccanismi autenticano parti diverse di una connessione e si configurano separatamente, come il riferimento delle opzioni 2.6 descrive. tls-auth aggiunge un HMAC ai pacchetti del canale di controllo e accetta un argomento di direzione che deve essere opposto sui due peer, mentre tls-crypt protegge il canale di controllo con una chiave condivisa invece. Nessuno dei due è il controllo di integrità proprio del canale dati. Con un cifrario dati AEAD quel controllo è integrato nel cifrario, quindi il auth digest separato non viene usato come con un cifrario non AEAD.

Il che significa che una riga auth copiata da un’implementazione non AEAD che funziona può essere irrilevante in una AEAD, e un’implementazione AEAD può ancora fallire sul canale di controllo se la tls-auth chiave o la sua direzione sono sbagliate. Confrontate ogni impostazione con il peer invece che con una configurazione ricordata.

Confrontate la correzione con la proprietà a cui rinunciate

Disattivare l’autenticazione dei pacchetti zittisce l’avviso e rimuove il controllo che ha trovato la discrepanza, il che non equivale a riparare il profilo. Chiedetevi quale proprietà state cedendo e se il progetto regge ancora senza.

Leggete il primo evento rilevante su entrambe le estremità prima di cambiare qualcosa, poi cambiate solo la discrepanza che nomina.

Se il tentativo successivo arriva a un errore di certificato o di accesso, è un progresso e non una regressione: il livello dei pacchetti ora concorda e la connessione è andata avanti. Annotate le impostazioni che hanno prodotto il cambiamento, così la persona successiva eredita una spiegazione invece di un mistero.