Kiel OpenConnect transformas ensalutan kuketon en tunelon?

OpenConnect ligas du apartajn interŝanĝojn per unu mallonga valoro: la reta ensaluto kaj la VPN-tunelo. La unua interŝanĝo estas ordinara HTTPS: legitimiloj, SAML-vojaĝo aŭ ĵetono iras al la enirejo, kaj la respondo portas aŭtentigan kuketon. La dua interŝanĝo prezentas tiun kuketon al la sama enirejo kiel pruvon, ke la reta fazo jam okazis, kaj nur tiam la tunelo ekstaras.

Pri la tunelo oni interkonsentas nenion dum la ensaluto. Tio estas la parto inda je kompreno, ĉar la plej multaj skript-eraroj supozas, ke la kuketo estas pasvorto por konservi aŭ ŝlosilo, kiu protektas trafikon, dum ĝi fakte estas portanto-bileto por difinita enireja sesio.

Kion la kliento kaj la enirejo interŝanĝas, laŭvice

La aŭtentiga fazo aspektas kiel ordinara protektita retejo. OpenConnect sendas la legitimilojn de la uzanto aŭ sekvas la alidirektadon de la enirejo al identecprovizanto, kaj la enirejo respondas per dokumento, kiu enigas la aŭtentigan kuketon. En la protokolo AnyConnect tiu valoro vojaĝas en kuketa kaplinio ĉe la sekvaj petoj, kutime sub nomo kiel webvpn, kaj la manlibro traktas ĝin kiel la legitimilon, kiu portas la sesion antaŭen.

La dua fazo estas CONNECT-peto al la VPN-finpunkto de la enirejo kun tiu kuketo alkroĉita. La enirejo kontrolas ĝin, asignas adreson, kaj la kliento ekigas CSTP super TLS, kun DTLS kiel laŭvola pli rapida datenvojo, kiam la sesio ekzistas. Nur en tiu ĉi punkto estiĝas la tunelaj parametroj, la vojoj, la DNS-agordoj kaj la trafikaj ŝlosiloj de la sesio. La kuketo pasigis la klienton tra la pordo; ĝi kriptis nenion.

Tiu sinsekvo klarigas, kial ekzistas openconnect --authenticate. Lanĉu ĝin, kaj ĝi plenumas la retan fazon, presas malgrandan blokon de ŝelvariabloj kiel COOKIE, HOST, CONNECT_URL kaj FINGERPRINT, kaj tiam finiĝas antaŭ ol iu tunelo konstruiĝas. Involukra skripto povas poste lanĉi la veran konekton per tiuj valoroj, kio estas ĝuste la divido, kiun bezonas senkapa aŭ du-kontenera surmeto.

La kuketo estas sesia portanto, ne ŝlosilo

Traktu la valoron tiel, kiel vi traktus sesian identigilon en reta aplikaĵo. Kiu tenas ĝin dum ĝia vivo, tiu povas peti de la enirejo la tunelon, kiun tiu sesio rajtas ricevi, do ĝia sekreteco gravas. Sed kopii ĝin ne malkaŝas trafikon, ĉar la konfideco de la tunelo venas de la TLS-manpremo kaj la derivitaj ŝlosiloj, ne de la kuketa ĉeno.

Ĝi ankaŭ ne estas daŭra permeso. La enirejo kaj la identecprovizanto decidas, kiom longe vivas la sesio, kaj retumilo, kiu ankoraŭ montras ensalutan paĝon, diras nenion pri tio, ĉu la tunela sesio ankoraŭ validas. Rekonekti post la fino signifas ripeti la retan fazon kaj produkti freŝan kuketon, kaj ĝuste tio estas la senco de reaŭtentigo, ne ĝenaĵo por ĉirkaŭiri per inĝenierado.

Ne traktu kuketon kiel universalan anstataŭaĵon por aliaj legitimiloj. SAML-aserto, retumila pasvorto kaj kuketo eldonita de alia servo estas malsamaj objektoj kun malsamaj publikaĵoj, kaj glui unu en la kampon de la alia kutime malsukcesas ĉe la enirejo aŭ, pli malbone, sukcesas kontraŭ la malĝusta fidlimo.

Transdoni la kuketon sen lasi kopiojn

La plej sekura mekanika transdono en Linukso estas la norma enigo. --cookie-on-stdin legas la valoron el stdin, do la kuketo neniam aperas en la argumenta listo de la procezo, kie iu loka uzanto povas legi ĝin per ps. Dukto, kiu aŭtentigas en unu procezo kaj nutras la tunelon en alia, tenas la valoron en tubo anstataŭ en dosiero aŭ medivariablo.

Argumentoj kaj medivariabloj estas pli malfortaj pro malsamaj kialoj. Argumento estas videbla en la procesa tabelo dum la tuta vivo de la kliento kaj ofte finiĝas en la ŝela historio. Medivariablo estas heredata de infanaj procezoj, kaj systemd-unuo, kiu agordas ĝin en la unua dosiero, konservas la sekreton en legebla agordo. Se dosiero estas necesa, limigu ĝin al la servokonto kaj forigu ĝin, kiam la sesio finiĝas.

Teniu ankaŭ la privilegian limon intenca. La procezo, kiu parolas kun la identecprovizanto kaj eble malfermas retumilon, devus kuri kiel la uzanto, al kiu apartenas tiu ensaluto. La procezo, kiu agordas vojojn, DNS kaj la tunelan aparaton, eble bezonas pli da privilegioj. Kuri la tutan retumilon kiel root, por ke ĝia kuketo estu havebla al root-posedata tunelo, estas la malĝusta interŝanĝo, kaj modernaj OpenConnect-agordoj povas eksplicite transdoni la valoron trans tiu limo.

Ankaŭ protokolado meritas la saman suspekton. Detala klienta eligo, helpaj skriptoj kaj enireja diagnozo povas ĉiuj ripeti petan materialon, kaj ne ĉiu protokola nivelo kaŝas la kuketon. Registru la plej malgrandan erarregistron, kiun vi bezonas, tenu ĝin ekster komunaj kanaloj, kaj kontrolu kaŝitan specimenon antaŭ ol aldoni ĝin al bileto.

Kontrolo kaj fino en la dua fazo

La dua fazo ankoraŭ devas kontroli la servilon. La FINGERPRINT, kiun --authenticate presas, estas atestila fiksilo en la formo pin-sha256:, kaj transdoni ĝin al la tunela alvoko per --servercert tenas la kontrolon ankrita al la enirejo, kontraŭ kiu vi aŭtentigis. Malkonekti la atestilan kontrolon por simpligi skripton forigas la solan pruvon, ke la kuketo estas transdonata al la celata gastiganto.

Kiam la enirejo rifuzas la kuketon, la solvo estas nova aŭtentiga raŭndo, ne pli longa kaŝmemoro. Konservu la kuketon nur dum la vivo de la konekto, forigu provizorajn dosierojn ĉe eliro, kaj uzu la sesi-forigan procezon de la identecprovizanto aŭ de la enirejo, kiam sesio malkaŝiĝas aŭ aparato perdiĝas. Kaŝmemorita kuketo ne estas escepto de MFA.

Antaŭ ol aŭtomatigi tion, kontrolu kvar aferojn: la tunelo kuras sub la ĝusta konto, la kuketo alvenas per stdin, la atestila fingrospuro estas fiksita, kaj la sesio estas forĵetata, kiam la tunelo fermiĝas. Se io mankas, la aŭtomatigo plivastigis la fidon al la kuketo anstataŭ reprodukti la permanan fluon.