Како OpenConnect претвара колачић за пријаву у тунел?

OpenConnect повезује две одвојене размене једном краткотрајном вредношћу: веб-пријаву и VPN тунел. Прва размена је обичан HTTPS: акредитиви, путовање SAML или токен иду ка порталу, а одговор носи колачић за аутентикацију. Друга размена представља тај колачић истом порталу као доказ да се веб-фаза већ догодила, и тек тада се тунел подиже.

Током пријаве ништа о тунелу се не договара. Управо то вреди разумети, јер већина грешака у скриптама претпоставља да је колачић лозинка коју треба сачувати или кључ који штити саобраћај, а он је заправо носива карта за одређену сесију портала.

Шта клијент и портал размењују, по реду

Фаза аутентикације изгледа као обичан заштићен веб-сајт. OpenConnect шаље акредитиве корисника или прати преусмеравање портала ка даваоцу идентитета, а портал одговара документом који уграђује колачић за аутентикацију. У протоколу AnyConnect та вредност путује у заглављу колачића при следећим захтевима, обично под именом као webvpn, и приручник је третира као акредитив који носи сесију напред.

Друга фаза је захтев CONNECT ка VPN крајњој тачки портала са тим колачићем приложеним. Портал га проверава, додељује адресу, и клијент покреће CSTP преко TLS-а, а DTLS је опционална брза путања података када сесија постоји. Тек у том тренутку успостављају се параметри тунела, руте, подешавања DNS-а и саобраћајни кључеви сесије. Колачић је провео клијента кроз врата; није шифровао ништа.

Овај редослед објашњава зашто постоји openconnect --authenticate. Покрените га и он извршава веб-фазу, штампа мали блок променљивих љуске као COOKIE, HOST, CONNECT_URL и FINGERPRINT, а затим излази пре него што се изгради било какав тунел. Омотач-скрипта затим може да покрене праву везу са тим вредностима, и то је управо подела која је потребна распоређивању без главе или у два контејнера.

Колачић је носилац сесије, не кључ

Односите се према вредности као према идентификатору сесије у веб-апликацији. Ко год га има током његовог живота може од портала да затражи тунел на који та сесија има право, зато је његова тајност важна. Али копирање не открива саобраћај, јер поверљивост тунела долази из TLS руковања и изведених кључева, а не из низа колачића.

То такође није трајна дозвола. Портал и давалац идентитета одлучују колико дуго сесија живи, а прегледач који још приказује пријављену страницу не говори ништа о томе да ли је сесија тунела још важећа. Поновно повезивање после истека значи поновити веб-фазу и створити свеж колачић, и управо је то смисао поновне аутентикације, а не незгода коју треба заобићи инжењерски.

Не третирајте колачић као универзалну замену за друге акредитиве. SAML тврдња, лозинка у прегледачу и колачић који је издала друга услуга различити су објекти са различитом публиком, а лепљење једног у поље другог обично не успева на порталу или, што је горе, успева против погрешне границе поверења.

Предаја колачића без остављених копија

Најбезбеднија механичка предаја на Linux-у је стандардни улаз. --cookie-on-stdin чита вредност из stdin-а, тако да се колачић никада не појављује на листи аргумената процеса, где га сваки локални корисник може прочитати помоћу ps. Цевовод који аутентикује у једном процесу и храни тунел у другом држи вредност у цеви, а не у датотеци или променљивој окружења.

Аргументи и променљиве окружења слабији су из различитих разлога. Аргумент је видљив у табели процеса током целог живота клијента и често заврши у историји љуске. Променљиву окружења наслеђују подређени процеси, а systemd јединица која је поставља у датотеци јединице чува тајну у читљивој конфигурацији. Ако је датотека неопходна, ограничите је на сервисни налог и уклоните је када се сесија заврши.

Одржавајте и границу привилегија свесно. Процес који разговара са даваоцем идентитета и можда отвара прегледач требало би да ради као корисник коме та пријава припада. Процес који конфигурише руте, DNS и уређај тунела може захтевати више привилегија. Покретање целог прегледача као root да би његов колачић био доступан тунелу у власништву root-а погрешна је размена, а савремена подешавања OpenConnect-а могу изричито да предају вредност преко те границе.

И евидентирање заслужује исту сумњу. Детаљан излаз клијента, помоћне скрипте и дијагностика портала могу да понове материјал захтева, а не сваки ниво евиденције сакрива колачић. Забележите најмањи запис о грешци који вам је потребан, држите га ван заједничких канала и прегледајте сакривени примерак пре него што га приложите тикету.

Провера и истек у другој фази

Друга фаза и даље мора да провери сервер. FINGERPRINT који штампа --authenticate је причвршћивање сертификата у облику pin-sha256:, а његово предавање позиву тунела са --servercert држи проверу усидрену на портал према коме сте се аутентиковали. Искључивање провере сертификата ради поједностављења скрипте уклања једини доказ да се колачић предаје предвиђеном домаћину.

Када портал одбије колачић, решење је нови круг аутентикације, а не дужи кеш. Чувајте колачић само за време трајања везе, бришите привремене датотеке при излазу и користите поступак уклањања сесије даваоца идентитета или портала када се сесија открије или уређај изгуби. Кеширани колачић није изузеће од MFA.

Пре него што ово аутоматизујете, проверите четири ствари: тунел ради под правим налогом, колачић стиже преко stdin-а, отисак сертификата је причвршћен и сесија се одбацује када се тунел затвори. Ако нешто недостаје, аутоматизација је проширила поверење у колачић уместо да понови ручни ток.