Hvordan forvandler OpenConnect en logincookie til en tunnel?

OpenConnect binder to separate udvekslinger sammen med én kortlivet værdi: webindlogningen og VPN-tunnelen. Den første udveksling er almindelig HTTPS: legitimationsoplysninger, en SAML-tur eller et token går til gatewayen, og svaret bærer en godkendelsescookie. Den anden udveksling fremviser den cookie for den samme gateway som bevis på, at webfasen allerede er sket, og først da rejses tunnelen.

Intet om tunnelen forhandles under indlogningen. Det er den del, der er værd at forstå, fordi de fleste fejl i scripts antager, at cookien er en adgangskode, der skal gemmes, eller en nøgle, der beskytter trafikken, mens den i virkeligheden er en bærerbillet til en bestemt gatewaysession.

Hvad klienten og gatewayen udveksler, i rækkefølge

Godkendelsesfasen ligner et almindeligt beskyttet websted. OpenConnect sender brugerens legitimationsoplysninger eller følger gatewayens omdirigering til en identitetsudbyder, og gatewayen svarer med et dokument, der indlejrer godkendelsescookien. I AnyConnect-protokollen rejser denne værdi i et cookie-header på de følgende anmodninger, normalt under et navn som webvpn, og manualen behandler den som den legitimationsoplysning, der bærer sessionen videre.

Den anden fase er en CONNECT-anmodning til gatewayens VPN-endpoint med cookien vedhæftet. Gatewayen kontrollerer den, tildeler en adresse, og klienten starter CSTP over TLS, med DTLS som en valgfri hurtigere datasti, når sessionen findes. Først på dette tidspunkt etableres tunnelparametre, ruter, DNS-indstillinger og sessionens trafiknøgler. Cookien fik klienten gennem døren; den krypterede intet.

Denne rækkefølge forklarer, hvorfor openconnect --authenticate findes. Kør den, og den udfører webfasen, udskriver en lille blok shell-variabler som COOKIE, HOST, CONNECT_URL og FINGERPRINT og afslutter derefter, før nogen tunnel bygges. Et wrapper-script kan så starte den rigtige forbindelse med disse værdier, og det er netop den opdeling, en headless eller to-container-opsætning har brug for.

Cookien er en sessionsbærer, ikke en nøgle

Behandl værdien, som du ville behandle et sessions-id i en webapplikation. Den, der holder den i dens levetid, kan bede gatewayen om den tunnel, som sessionen har ret til, så dens hemmeligholdelse er vigtig. Men at kopiere den afslører ikke trafik, fordi tunnelens fortrolighed kommer fra TLS-handshaket og de afledte nøgler, ikke fra cookiestrengen.

Den er heller ikke en permanent bevilling. Gatewayen og identitetsudbyderen afgør, hvor længe sessionen lever, og en browser, der stadig viser en indlogget side, siger intet om, hvorvidt tunnelsessionen stadig er gyldig. Genopkobling efter udløb betyder at gentage webfasen og frembringe en frisk cookie, og det er netop meningen med reautentificering, ikke en gene, der skal konstrueres rundt om.

Behandl ikke en cookie som en universel erstatning for andre legitimationsoplysninger. En SAML-erklæring, en browseradgangskode og en cookie udstedt af en anden tjeneste er forskellige objekter med forskellige målgrupper, og at sætte den ene ind i den andens felt fejler normalt ved gatewayen eller, værre, lykkes over for den forkerte tillidsgrænse.

Videresend cookien uden at efterlade kopier

Den sikreste mekaniske overlevering på Linux er standardinput. --cookie-on-stdin læser værdien fra stdin, så cookien aldrig vises i processens argumentliste, hvor enhver lokal bruger kan læse den med ps. En pipeline, der godkender i én proces og fodrer tunnelen i en anden, holder værdien i et rør i stedet for i en fil eller en miljøvariabel.

Argumenter og miljøvariabler er svagere af forskellige grunde. Et argument er synligt i procestabellen i hele klientens levetid og ender ofte i shell-historikken. En miljøvariabel nedarves til underprocesser, og en systemd-unit, der sætter den i unit-filen, gemmer hemmeligheden i en læsbar konfiguration. Hvis en fil er nødvendig, skal du begrænse den til tjenestekontoen og fjerne den, når sessionen slutter.

Hold også privilegiegrænsen bevidst. Den proces, der taler med identitetsudbyderen og muligvis åbner en browser, bør køre som den bruger, der ejer den indlogning. Den proces, der konfigurerer ruter, DNS og tunnelanordningen, kan have brug for flere rettigheder. At køre hele browseren som root for at gøre dens cookie tilgængelig for en root-ejet tunnel er den forkerte byttehandel, og moderne OpenConnect-opsætninger kan udtrykkeligt give værdien videre over den grænse.

Logning fortjener samme mistanke. Verbose klientoutput, hjælpescripts og gatewaydiagnostik kan alle gengive anmodningsmateriale, og ikke alle logniveauer maskerer cookien. Fang den mindste fejlpost, du har brug for, hold den ude af delte kanaler, og kontroller en maskeret prøve, før du vedhæfter den til en sag.

Verifikation og udløb i den anden fase

Den anden fase skal stadig verificere serveren. Det FINGERPRINT, som --authenticate udskriver, er en certifikatpin i formen pin-sha256:, og at give det videre til tunnelkaldet med --servercert holder kontrollen forankret i den gateway, du godkendte dig over for. At slå certifikatkontrol fra for at gøre et script enklere fjerner det eneste bevis for, at cookien gives til den tilsigtede vært.

Når gatewayen afviser cookien, er løsningen en ny godkendelsesrunde, ikke en længere cache. Gem kun cookien i forbindelsens levetid, slet midlertidige filer ved afslutning, og brug identitetsudbyderens eller gatewayens sessionsfjernelsesproces, når en session afsløres, eller en enhed mistes. En cachet cookie er ikke en fritagelse for MFA.

Før du automatiserer dette, skal du kontrollere fire ting: tunnelen kører under den rigtige konto, cookien ankommer via stdin, certifikatets fingeraftryk er pinnet, og sessionen kasseres, når tunnelen lukkes. Hvis noget af det mangler, har automatiseringen udvidet tilliden til cookien i stedet for at genskabe det manuelle flow.