OpenVPN tls-crypt-v2: què fan la clau del client i el blob embolicat
Un perfil tls-crypt-v2 conté una clau de control del client i una còpia embolicada que només el servidor pot obrir. Mantingueu cada objecte, i cada pas de retirada, per separat.
Enganxar un perfil tls-crypt-v2 en un tiquet sembla inofensiu fins que compteu què conté el fitxer. La clau del canal de control del client se situa al costat d'una còpia xifrada d'aquesta mateixa clau, i un tercer objecte, la clau d'embolcall, no surt mai del servidor que accepta. Aquests tres responen preguntes diferents sobre custòdia, compartició i retirada. Separar-los resol la majoria de discussions de política abans que comencin.
Què conté realment el perfil
La meitat del client de tls-crypt-v2 és una clau més una còpia embolicada seva. El client utilitza la clau plana per a la protecció del canal de control i lliura la còpia embolicada al servidor durant la configuració, de manera que el servidor recupera la mateixa clau sense desar una còpia en text pla per client. La clau d'embolcall fa possible aquesta recuperació i pertany només al costat que accepta. Tot el que segueix es deriva d'on viuen aquests tres objectes.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
Llegiu la taula per custòdia i no per nom, i les conseqüències surten soles. Perdre la clau d'embolcall és l'esdeveniment car, perquè res del perfil no la pot reconstruir i la recuperació honesta és tornar a emetre el grup. Un perfil filtrat és més barat però molt més freqüent, perquè els perfils s'enganxen als tiquets per gent que creu que la còpia embolicada fa que el fitxer sigui segur de compartir. Els dos fracassos necessiten respostes diferents, i aquesta és la raó de mantenir els objectes separats.
Per què la còpia embolicada no és tota la història
Un perfil porta el material de client utilitzable juntament amb la seva contrapart embolicada, així que protegir la còpia per al servidor no diu res sobre protegir el fitxer. El blob és segur de transmetre i insegur de publicar. Les metadades que conté són visibles per a qui rebi el blob, incloent-hi qui més endavant llegeixi el tiquet on es va enganxar.
Tracteu un perfil com una credencial i no com una mostra de configuració. Un fitxer filtrat dona al seu posseïdor una identitat de client operativa fins que el servidor deixi d'acceptar aquesta identitat, i l'embolcall no fa res respecte d'aquesta finestra. Emeteu un perfil per client perquè la retirada segueixi sent una decisió d'un sol fitxer, i feu una còpia de seguretat de la clau d'embolcall separada de la configuració del servidor que habilita. Cap dels dos hàbits no repara un perfil compromès, però tots dos decideixen amb quina rapidesa es contindrà el següent.
On se situa el hook de verificació a l'apretada de mans
El hook de verificació s'executa abans que s'exposi la pila TLS, i la seva feina és inspeccionar les metadades que porta el blob embolicat. Rep aquestes metadades més un entorn petit i documentat, i té menys eines que un hook d'autenticació. Suposar que pot veure noms d'usuari, estat de sessió o variables de connectors és la manera habitual que aquest hook s'escrigui malament. Llegiu la secció pròpia del manual del hook en lloc de manllevar expectatives d'un altre hook.
El seu estat de sortida és la decisió: un resultat diferent de zero rebutja el client i un resultat zero deixa continuar l'apretada de mans. Per tant, la política ha de dir què passa quan les metadades falten, no es poden analitzar o són inesperades. Escriviu primer el camí de rebuig i després decidiu quins valors són acceptables.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shAquestes dues línies són la superfície de política al servidor: una nomena la clau d'embolcall, l'altra nomena el programa que jutja cada client. Tot el que és interessant viu a l'script, que mereix control de versions i la mateixa revisió que qualsevol altra regla d'accés.
Compte, certificat i clau de control es retiren per separat
L'acceptació primerenca del canal de control no és autenticació, perquè passa abans de la comprovació d'identitat TLS i abans de qualsevol autorització de compte. Desactivar un compte, revocar un certificat i rebutjar una clau de control de client són tres accions amb tres mecanismes. Un desplegament que només en fa una té un buit i no una política. Reconcilieu les tres deliberadament i registreu quin pas exerceix quina autoritat.
El moment és la segona distinció. Una llista d'acceptació canviada s'aplica a les noves apretades de mans, mentre que les sessions ja establertes continuen fins que alguna cosa les aturi. Comptar entrades de la llista nova com a prova que les sessions antigues han acabat és com un client eliminat continua connectat durant hores.
Les autoritats no reconciliades deixen dos forats fàcils de trobar a la pràctica. Un compte es pot desactivar mentre la seva clau de control encara obre una apretada de mans, i un certificat es pot revocar mentre la política de metadades encara admet el mateix client. Tots dos són el mateix error en llocs diferents, perquè un operador va tractar una llista com tota l'autoritat. Posa les tres llistes costat a costat en el moment de l'eliminació i l'error es fa visible.
Emetre i retirar un perfil
Emetre és la meitat fàcil: creeu la clau del client al costat que accepta, lliureu el perfil a exactament un propietari, manteniu restringit el material d'embolcall i executeu el mateix programa de verificació a cada servidor que accepta. L'admissió barata és una propietat de tot el grup, no de l'amfitrió més nou. Un segon servidor amb un script més antic o més lax es converteix en silenci en el camí més feble del desplegament.
La retirada necessita els tres passos en un ordre deliberat. Denegueu el client al hook de verificació perquè fallin les noves apretades de mans, revoqueu el seu certificat si s'utilitza una PKI i desactiveu el compte perquè l'autorització posterior no tingui res a autoritzar. A continuació, atureu les sessions que l'acceptació antiga permetia, ja que no notaran cap de les tres. Assageu la seqüència amb un client que us pugueu permetre trencar.
Les metadades d'un perfil són una entrada per a aquesta política, no una prova que el control d'accés ja existeixi. El document de disseny d'OpenVPN 2.6 descriu els objectes i la frontera que dibuixen, mentre que aplicar-los continua sent cosa de l'operador.