Com converteix OpenConnect una galeta d’inici de sessió en un túnel?
OpenConnect bescanvia una galeta d’inici de sessió web per un túnel VPN. La galeta és un portador de la sessió, així que protegiu el lliurament, no només la pàgina d’accés.
OpenConnect lliga dos intercanvis separats amb un sol valor de curta durada: l’inici de sessió web i el túnel VPN. El primer intercanvi és HTTPS ordinari: les credencials, un anada i tornada SAML o un testimoni van a la passarel·la, i la resposta porta una galeta d’autenticació. El segon intercanvi presenta aquesta galeta a la mateixa passarel·la com a prova que la fase web ja ha passat, i només llavors s’aixeca el túnel.
Durant l’inici de sessió no es negocia res del túnel. Aquesta és la part que val la pena entendre, perquè la majoria d’errors d’script assumeixen que la galeta és una contrasenya per desar, o una clau que protegeix el trànsit, quan en realitat és un bitllet al portador per a una sessió concreta de la passarel·la.
Què intercanvien el client i la passarel·la, per ordre
La fase d’autenticació sembla un lloc web protegit normal. OpenConnect envia les credencials de l’usuari, o segueix la redirecció de la passarel·la cap a un proveïdor d’identitat, i la passarel·la respon amb un document que incrusta la galeta d’autenticació. En el protocol AnyConnect aquest valor viatja en una capçalera de galeta a les peticions següents, normalment amb un nom com webvpn, i el manual el tracta com la credencial que porta la sessió endavant.
La segona fase és una petició CONNECT al punt final VPN de la passarel·la amb aquesta galeta adjunta. La passarel·la la comprova, assigna una adreça, i el client inicia CSTP sobre TLS, amb DTLS com a camí de dades opcional més ràpid un cop existeix la sessió. Només en aquest moment s’estableixen els paràmetres del túnel, les rutes, la configuració DNS i les claus de trànsit de la sessió. La galeta va fer passar el client per la porta; no va xifrar res.
Aquesta seqüència explica per què existeix openconnect --authenticate. Executeu-lo i fa la fase web, imprimeix un petit bloc de variables d’intèrpret com COOKIE, HOST, CONNECT_URL i FINGERPRINT, i després surt abans de construir cap túnel. Un script embolcall pot llavors iniciar la connexió real amb aquests valors, que és exactament la divisió que necessita un desplegament sense interfície o en dos contenidors.
La galeta és un portador de sessió, no una clau
Tracteu el valor com tractaríeu un identificador de sessió en una aplicació web. Qui el tingui durant la seva vida pot demanar a la passarel·la el túnel al qual aquesta sessió té dret, així que la seva secreticitat importa. Però copiar-lo no revela trànsit, perquè la confidencialitat del túnel ve de l’apretada de mans TLS i de les claus derivades, no de la cadena de la galeta.
També no és una concessió permanent. La passarel·la i el proveïdor d’identitat decideixen quant viu la sessió, i un navegador que encara mostra una pàgina amb sessió oberta no diu res sobre si la sessió del túnel encara és vàlida. Tornar a connectar després del venciment vol dir repetir la fase web i produir una galeta nova, i aquest és el sentit de la reautenticació, no una molèstia per enginyar-hi una volta.
No tracteu una galeta com a substitut universal d’altres credencials. Una asserció SAML, una contrasenya de navegador i una galeta emesa per un altre servei són objectes diferents amb audiències diferents, i enganxar-ne un al camp de l’altre normalment falla a la passarel·la o, pitjor, té èxit contra el límit de confiança equivocat.
Passar la galeta sense deixar còpies
El lliurament mecànic més segur a Linux és l’entrada estàndard. --cookie-on-stdin llegeix el valor de stdin, així que la galeta no apareix mai a la llista d’arguments del procés, on qualsevol usuari local la pot llegir amb ps. Una canonada que autentica en un procés i alimenta el túnel en un altre manté el valor en una canonada en lloc d’un fitxer o una variable d’entorn.
Els arguments i les variables d’entorn són més febles per motius diferents. Un argument és visible a la taula de processos durant la vida del client i sovint acaba a l’historial de l’intèrpret. Una variable d’entorn s’hereta als processos fills, i una unitat de systemd que la defineix al fitxer d’unitat desa el secret en una configuració llegible. Si cal un fitxer, limiteu-lo al compte de servei i elimineu-lo quan acabi la sessió.
Mantingueu també el límit de privilegis deliberat. El procés que parla amb el proveïdor d’identitat i potser obre un navegador hauria de córrer com l’usuari a qui pertany aquest inici de sessió. El procés que configura rutes, DNS i el dispositiu del túnel pot necessitar més privilegis. Fer córrer tot el navegador com a root perquè la seva galeta estigui disponible per a un túnel propietat de root és el mal intercanvi, i les configuracions modernes d’OpenConnect poden passar el valor per aquest límit explícitament.
El registre mereix la mateixa sospita. La sortida detallada del client, els scripts auxiliars i el diagnòstic de la passarel·la poden repetir material de la petició, i no tots els nivells de registre redacten la galeta. Captureu el registre d’error més petit que necessiteu, manteniu-lo fora de canals compartits i reviseu una mostra redactada abans d’adjuntar-la a un tiquet.
Verificació i venciment a la segona fase
La segona fase encara ha de verificar el servidor. El FINGERPRINT que imprimeix --authenticate és un ancoratge de certificat en forma pin-sha256:, i passar-lo a la invocació del túnel amb --servercert manté la comprovació ancorada a la passarel·la contra la qual us heu autenticat. Desactivar la comprovació de certificats per simplificar un script elimina l’única prova que la galeta es lliura a l’amfitrió previst.
Quan la passarel·la rebutja la galeta, la solució és una nova ronda d’autenticació, no una memòria cau més llarga. Deseu la galeta només per la vida de la connexió, suprimiu els fitxers temporals en sortir i feu servir el procés de retirada de sessió del proveïdor d’identitat o de la passarel·la quan una sessió quedi exposada o es perdi un dispositiu. Una galeta desada no és una exempció de MFA.
Abans d’automatitzar això, verifiqueu quatre coses: el túnel corre amb el compte correcte, la galeta arriba per stdin, l’empremta del certificat està ancorada i la sessió es descarta quan el túnel es tanca. Si en falta alguna, l’automatització ha ampliat la confiança en la galeta en lloc de reproduir el flux manual.