Hvordan gjør OpenConnect en informasjonskapsel om til en tunnel?

OpenConnect binder to separate utvekslinger sammen med én kortlevd verdi: webpåloggingen og VPN-tunnelen. Den første utvekslingen er vanlig HTTPS: legitimasjon, en SAML-rundtur eller et token går til gatewayen, og svaret bærer en autentiseringskapsel. Den andre utvekslingen legger fram den kapselen for samme gateway som bevis på at webfasen allerede har skjedd, og først da reises tunnelen.

Under påloggingen forhandles ingenting om tunnelen. Det er den delen som er verdt å forstå, fordi de fleste skriptfeil antar at kapselen er et passord som skal lagres, eller en nøkkel som beskytter trafikken, mens den egentlig er en bærerbillett for en bestemt gatewayøkt.

Hva klienten og gatewayen utveksler, i rekkefølge

Autentiseringsfasen ser ut som et vanlig beskyttet nettsted. OpenConnect sender brukerens legitimasjon, eller følger gatewayens omdirigering til en identitetsleverandør, og gatewayen svarer med et dokument som bygger inn autentiseringskapselen. I AnyConnect-protokollen reiser denne verdien i en kapselheader på de neste forespørslene, vanligvis under et navn som webvpn, og håndboken behandler den som legitimasjonen som bærer økten videre.

Den andre fasen er en CONNECT-forespørsel til gatewayens VPN-endepunkt med kapselen vedlagt. Gatewayen kontrollerer den, tildeler en adresse, og klienten starter CSTP over TLS, med DTLS som en valgfri raskere datastasjon når økten finnes. Først på dette tidspunktet etableres tunnelparametere, ruter, DNS-innstillinger og øktens trafikknøkler. Kapselen slapp klienten gjennom døren; den krypterte ingenting.

Denne rekkefølgen forklarer hvorfor openconnect --authenticate finnes. Kjør den, og den utfører webfasen, skriver ut en liten blokk med skallvariabler som COOKIE, HOST, CONNECT_URL og FINGERPRINT, og avslutter før noen tunnel bygges. Et innpakningsskript kan da starte den virkelige forbindelsen med disse verdiene, og det er nettopp oppdelingen en hodeløs eller tobeholders utrulling trenger.

Kapselen er en øktbærer, ikke en nøkkel

Behandle verdien slik du ville behandlet en økt-ID i en webapplikasjon. Den som holder den i levetiden, kan be gatewayen om tunnelen som økten har rett til, så hemmeligholdelsen er viktig. Men å kopiere den avdekker ikke trafikk, fordi tunnelens konfidensialitet kommer fra TLS-håndtrykket og de avledede nøklene, ikke fra kapselstrengen.

Den er heller ikke en permanent tillatelse. Gatewayen og identitetsleverandøren bestemmer hvor lenge økten lever, og en nettleser som fortsatt viser en pålogget side, sier ingenting om tunneløkten fortsatt er gyldig. Å koble til på nytt etter utløp betyr å gjenta webfasen og produsere en fersk kapsel, og det er nettopp poenget med reautentisering, ikke en plage som skal konstrueres bort.

Ikke behandle en kapsel som en universell erstatning for annen legitimasjon. En SAML-påstand, et nettleserpassord og en kapsel utstedt av en annen tjeneste er forskjellige objekter med forskjellige målgrupper, og å lime den ene inn i den andres felt mislykkes vanligvis ved gatewayen eller, verre, lykkes mot feil tillitsgrense.

Å levere kapselen uten å etterlate kopier

Den sikreste mekaniske overleveringen på Linux er standardinndata. --cookie-on-stdin leser verdien fra stdin, så kapselen vises aldri i prosessens argumentliste, der enhver lokal bruker kan lese den med ps. En pipeline som autentiserer i én prosess og mater tunnelen i en annen, holder verdien i et rør i stedet for i en fil eller en miljøvariabel.

Argumenter og miljøvariabler er svakere av ulike grunner. Et argument er synlig i prosesstabellen gjennom hele klientens levetid og havner ofte i skallhistorikken. En miljøvariabel arves av barneprosesser, og en systemd-enhet som setter den i enhetsfilen, lagrer hemmeligheten i en lesbar konfigurasjon. Hvis en fil er nødvendig, begrens den til tjenestekontoen og fjern den når økten slutter.

Hold også privilegiegrunnlaget bevisst. Prosessen som snakker med identitetsleverandøren og kanskje åpner en nettleser, bør kjøre som brukeren som eier den påloggingen. Prosessen som konfigurerer ruter, DNS og tunnelenheten, kan trenge mer privilegier. Å kjøre hele nettleseren som root for at kapselen skal være tilgjengelig for en root-eid tunnel er den gale byttehandelen, og moderne OpenConnect-oppsett kan overlevere verdien over den grensen eksplisitt.

Logging fortjener samme mistanke. Detaljert klientutdata, hjelpeskript og gatewaydiagnostikk kan alle gjenta forespørselsmateriale, og ikke alle loggnivåer maskerer kapselen. Fang den minste feilposten du trenger, hold den utenfor delte kanaler, og sjekk en maskert prøve før du legger den ved en sak.

Verifisering og utløp i den andre fasen

Den andre fasen må fortsatt verifisere serveren. Den FINGERPRINT som --authenticate skriver ut, er en sertifikatpinne i formen pin-sha256:, og å gi den til tunnelkallet med --servercert holder kontrollen forankret i gatewayen du autentiserte deg mot. Å slå av sertifikatkontrollen for å gjøre et skript enklere fjerner det eneste beviset på at kapselen leveres til den tiltenkte verten.

Når gatewayen avviser kapselen, er løsningen en ny autentiseringsrunde, ikke en lengre hurtigbuffer. Lagre kapselen bare så lenge forbindelsen varer, slett midlertidige filer ved avslutning, og bruk identitetsleverandørens eller gatewayens prosess for fjerning av økt når en økt avdekkes eller en enhet mistes. En bufret kapsel er ikke en fritakelse fra MFA.

Før du automatiserer dette, verifiser fire ting: tunnelen kjører under riktig konto, kapselen kommer inn via stdin, sertifikatets fingeravtrykk er pinnet, og økten forkastes når tunnelen lukkes. Hvis noe av dette mangler, har automatiseringen utvidet tilliten til kapselen i stedet for å gjenskape den manuelle flyten.