OpenVPN auth-nocache: cosa succede al prossimo accesso

Attivate auth-nocache e l’avviso sulla cache della password scompare, insieme alla copia delle credenziali che OpenVPN teneva per la prossima rinegoziazione. Se questo diventi una richiesta, un nuovo tentativo silenzioso o un tunnel interrotto dipende da dove arrivano le credenziali la seconda volta. Questo ne fa un confronto tra forme di distribuzione e non un verdetto sull’opzione. Leggete la forma che eseguite davvero prima di modificare qualsiasi profilo.

Da dove deve arrivare il secondo insieme di credenziali

OpenVPN applica auth-nocache ai segreti raccolti da auth-user-pass e askpass: una volta usati, il processo li scarta invece di conservarli per la stretta di mano successiva. Una rinegoziazione arriva a tempo, una volta all’ora per impostazione predefinita, quindi la seconda richiesta arriva molto dopo che la persona che ha digitato la password se n’è andata. Quel vuoto è tutta la storia. Con la cache attiva, il client riproduce la copia salvata senza chiedere a nessuno; con la cache disattivata, deve trovare il segreto altrove o fallire.

Quindi elencate ogni luogo da cui il segreto potrebbe arrivare in quel momento, e siate onesti su quali esistono sull’host. Una persona davanti a un terminale, un file che auth-user-pass o askpass possono leggere, o un token di sessione emesso dal server sono i tre che contano qui. Se nessuno è disponibile, la rinegoziazione fallisce un’ora dopo la modifica e non nel momento in cui l’avete fatta.

Tre forme, tre punti di guasto

Un client desktop con una persona davanti è il caso lieve: la richiesta torna, qualcuno digita di nuovo la password e il costo è attenzione. Un servizio, un container o un router che esegue OpenVPN senza terminale è il caso duro, perché nessuno è lì a rispondere e la riconnessione un tempo silenziosa ora chiude il tunnel. Un ibrido sta tra i due e si comporta come il caso desktop finché non sparisce la sessione che poteva rispondere alla richiesta. Ciò che li separa non è la presenza di una GUI, ma l’esistenza di una fonte di credenziali al momento della rinegoziazione.

Associate la vostra distribuzione a una di queste tre forme prima di cambiare qualcosa, perché il consiglio che trovate online è quasi sempre scritto per la prima. Applicare la risposta desktop a un servizio senza terminale è il modo in cui un tunnel che ha funzionato per mesi inizia a cadere ogni ora.

Direttiva o flag: sceglietene uno e sappiate quale avete usato

Dentro un profilo, auth-nocache è una riga a sé; in una chiamata che nomina esplicitamente un profilo, è un flag su quella riga di comando, e il manuale di OpenVPN elenca entrambe le forme. Entrambi fanno lo stesso alla conservazione delle credenziali, e nessuno tocca il tipo di interfaccia né ripara un avviso non correlato nello stesso registro. La differenza è la persistenza: il flag copre solo quella esecuzione, quindi un servizio riavviato da un file unit o da uno script wrapper non lo avrà, a meno che il wrapper non lo passi anche.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Decidete quale artefatto possiede l’impostazione, cambiatela lì e da nessun’altra parte. Un profilo modificato su un portatile più una unit systemd che lo sovrascrive con un flag è la coppia che produce un comportamento contraddittorio dopo un riavvio.

Un file di credenziali sposta il segreto invece di eliminarlo

Puntare auth-user-pass a un file dà una fonte a ogni rinegoziazione successiva, e mette anche la password in un posto che sopravvive ai riavvii. Chiedete chi può leggere quel file, se il demone può ancora leggerlo dopo aver rinunciato ai privilegi e cosa succede quando il filesystem è montato in sola lettura o una vista container nasconde il percorso. Un segreto su disco e un segreto in memoria sono problemi diversi, e risolverne uno lascia l’altro al suo posto. La rotazione è il passo che viene saltato: una password cambiata sul server ma non nel file produce un guasto che si legge come un errore di rete.

Mantenete il file di proprietà dell’account che esegue il demone, leggibile da nessun altro, e fuori dai backup che lasciano l’host. L’opzione auth-gen-token lato server di OpenVPN consegna al client un token di sessione dopo un accesso riuscito, che è una cosa più piccola da lasciare in giro rispetto alla password dell’account. Scrivete il passo di rotazione accanto al file in ogni caso, perché il file di solito sopravvive alla persona che l’ha creato.

Allungare la rinegoziazione sposta il costo, non lo elimina

L’altro suggerimento è alzare reneg-sec finché la richiesta non è abbastanza rara da poterla ignorare. Questo riscrive il calendario di rotazione delle chiavi della sessione e spinge lo stesso problema delle credenziali a un momento più tardo e meno prevedibile; non crea una fonte di credenziali. Una politica che rinnova le chiavi secondo un calendario per qualche motivo non dovrebbe essere allentata solo per evitare di digitare una password.

Testate la riconnessione invece della sessione in cui siete seduti, perché la sessione viva non dimostra nulla. Fate cadere il tunnel dal lato server, o riavviate il servizio client, e osservate cosa fa la prossima rinegoziazione senza nessuno alla tastiera. Se si riconnette, nominate il meccanismo che ha fornito il segreto; se no, avete trovato il costo reale dell’opzione su questo host. Qualunque esito vi dà una risposta che regge durante un’interruzione invece di una che ha retto durante i test.

Su una flotta gestita, chi possiede la distribuzione dovrebbe saper nominare tre cose: da dove arrivano le credenziali, dove sono conservate e chi le ruota. Se una di queste risposte è la persona che ha configurato l’host, l’opzione non è ancora sicura lì.