Како 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, отпечатокот на сертификатот е прицврстен и сесијата се отфрла кога тунелот се затвора. Ако нешто од тоа недостасува, автоматизацијата ја проширила довербата во колачето наместо да го репродуцира рачниот тек.