Per què openssl rand no pot crear la clau que tls-crypt vol

OpenSSL ja està instal·lat, l’amfitrió té entropia, i generar una clau amb ell sembla el curtcircuit obvi. La sortida serà aleatòria i secreta i completament inutilitzable, i la fallada arriba com a error del canal de control en lloc de com una cosa que esmenti un format de clau. Aquest engany és la part cara, perquè envia la gent a inspeccionar els seus xifrats. El que llegeix la VPN és una estructura de fitxer concreta, no un bloc arbitrari de bytes, i una variant de la funció no es pot produir fora del servidor de cap manera.

Què ha de ser realment el fitxer al disc

Un fitxer de clau estàtica d’OpenVPN és text. Comença amb una línia de comentari que declara què és, porta dades hexadecimals en files d’amplada fixa i suma 256 bytes de material de clau. OpenVPN el llegeix com el secret compartit del canal de control, no com un certificat, no com una frase de pas i no com una cosa que una biblioteca TLS reconeixeria.

El mateix tipus d’objecte serveix les dues funcions del canal de control. Amb tls-auth, cada parell també necessita una direcció perquè els paquets d’un costat no es puguin reflectir de tornada cap a ell. Amb tls-crypt, un únic secret compartit xifra i autentica el canal de control en tots dos sentits, cosa que amaga l’encaixada de mans i alhora la protegeix.

Res d’això no és coneixement secret, i el format no és el punt. El punt és que el fitxer ha de coincidir exactament amb el que el lector espera: capçalera, amplada de fila, salt de línia final i longitud total. Un fitxer que es desvia en una fila es carrega com a escombraries o falla directament. Comparar dos parells byte a byte és, per tant, una primera prova legítima, i és més ràpid que llegir qualsevol dels dos fitxers de configuració.

La manera admesa de crear-ne un

Genereu la clau estàtica simple amb l’eina que la consumirà i, després, referencieu-la des dels dos extrems:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

L’ortografia de l’opció va canviar amb el temps: les instal·lacions antigues de l’era 2.4 feien servir una forma amb un indicador separat abans del nom del fitxer, mentre que les compilacions actuals accepten la més curta. En qualsevol cas, el fitxer resultant és el mateix tipus d’objecte, així que la comprovació és si tots dos parells tenen bytes idèntics.

La segona generació afegeix una estructura que cap generador extern no pot inventar. Una clau de servidor es crea una vegada, i cada client rep una clau embolcallada derivada d’ella:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

El que rep el client no és la pròpia clau del servidor duplicada. És un objecte embolcallat que porta metadades que només el servidor pot desembolcallar, i aquest embolcallament és la raó per la qual un fitxer per dispositiu es pot revocar sense tocar cap altre dispositiu. Mantingueu la clau del servidor al servidor i tracteu-la com l’arrel d’aquesta confiança per dispositiu.

On fallen els bytes fets a mà

Imprimir 256 bytes aleatoris com a hexadecimal sota una capçalera correcta donaria, en teoria, un fitxer de clau estàtica que es carrega. Continua sent una mala idea. Cada detall de format es converteix en una ocasió de produir material que falla en carregar o, pitjor, deixa dos parells amb valors diferents que només es revelen com una fallada d’autenticació.

Res d’equivalent no és possible amb la variant v2. Una clau de client embolcallada només existeix com a sortida del procés de clau del servidor, i el servidor conserva el material necessari per desembolcallar-la. Un bloc aleatori serà rebutjat o simplement fallarà en desxifrar, i cap dels dos missatges no esmentarà l’atzar.

La compatibilitat de versions se superposa a tot això. La primera generació necessita una versió que la admeti als dos extrems, i la segona necessita encara una versió més nova. Un client compilat abans que la funció existís no pot completar una encaixada de mans amb un servidor que només accepta material embolcallat, i la fallada que informa apunta al canal de control en lloc de a la versió.

Fer rotació sense deixar tothom fora

Fer rotar un únic secret compartit és un exercici de coordinació, no tècnic. Cada client necessita el fitxer de substitució a mà abans que el servidor retiri l’anterior, i qualsevol màquina que encara tingui el valor antic falla en el moment que això passa. No comenceu aquesta rotació enmig d’una jornada laboral.

Amb la disposició v2, la rotació és per dispositiu: emeteu una clau embolcallada nova per a una màquina i retireu l’antiga només per a aquesta màquina. Aquest és l’argument principal per canviar un cop cada client és en una versió que ho admet.

Els permisos de fitxer pertanyen a la mateixa conversa. La clau hauria de ser llegible només pel compte que executa el servei, i no hauria de viure al mateix repositori que els perfils que protegeix. La referència d’OpenVPN 2.6 documenta les formes de generació i les seccions de material de clau, que és una font millor que una ordre copiada d’una publicació de fòrum.