Уставіць профіль tls-crypt-v2 у заяўку выглядае бясшкодна, пакуль не палічыш, што змяшчае файл. Ключ кантрольнага канала кліента стаіць побач з шыфраванай копіяй таго ж ключа, а трэці аб'ект — ключ загортвання — ніколі не пакідае сервер, што прымае. Гэтыя тры адказваюць на розныя пытанні пра захоўванне, абмен і адкліканне. Іх падзел здымае большасць спрэчак пра палітыку яшчэ да іх пачатку.

Што профіль насамрэч змяшчае

Кліенцкая палова tls-crypt-v2 — гэта ключ плюс загорнутая яго копія. Кліент выкарыстоўвае звычайны ключ для абароны кантрольнага канала і перадае загорнутую копію серверу падчас наладжвання, так што сервер аднаўляе той самы ключ, не захоўваючы тэкставую копію для кожнага кліента. Ключ загортвання робіць гэтае аднаўленне магчымым і належыць толькі прымаючаму боку. Усё ніжэй вынікае з таго, дзе жывуць гэтыя тры аб'екты.

ObjectWhere it livesWhat can open itWhat a leak costs
Server wrapping keyaccepting servers onlythe unwrap step inside the serverevery wrapped copy issued to that group becomes readable
Wrapped client keyinside the client profilethe server wrapping keyit names a client and exposes its metadata, but not the key inside
Client control keyinside the client profile, usable as-isthe client that owns itsomeone can open handshakes as that client until the server refuses the key

Чытайце табліцу па захоўванні, а не па назве, і наступствы выяўляюцца самі. Страта ключа загортвання — гэта дарагое здарэнне, бо нішто ў профілі не можа яго аднавіць, і сумленнае аднаўленне — гэта перавыпуск групы. Уцечка профілю таннейшая, але значна больш распаўсюджаная, бо профілі ўстаўляюць у заяўкі людзі, якія вераць, што загорнутая копія робіць файл бяспечным для абмену. Дзве няўдачы патрабуюць розных адказаў, і менавіта таму аб'екты трымаюць асобна.

Чаму загорнутая копія — не ўся гісторыя

Профіль нясе прыдатны да ўжывання кліенцкі матэрыял разам з яго загорнутым адпаведнікам, таму абарона копіі для сервера нічога не кажа пра абарону файла. Blob бяспечна перадаваць і небяспечна публікаваць. Метаданыя ўнутры бачныя кожнаму, хто атрымлівае blob, у тым ліку таму, хто пазней чытае заяўку, куды яго ўставілі.

Стаўцеся да профілю як да пасведчання, а не як да ўзору канфігурацыі. Файл, які ўцёк, дае ўладальніку працоўную ідэнтычнасць кліента, пакуль сервер не перастане прымаць гэтую ідэнтычнасць, і загортванне нічога не робіць з гэтым акном. Выдавайце адзін профіль на кліента, каб адкліканне заставалася рашэннем пра адзін файл, і рабіце рэзервовую копію ключа загортвання асобна ад канфігурацыі сервера, якую ён уключае. Ні адна з гэтых звычак не выпраўляе скампраметаваны профіль, але абедзве вызначаюць, як хутка будзе стрыманы наступны.

Дзе хук праверкі стаіць у рукапацісканні

Хук праверкі працуе да таго, як прадставіцца стэк TLS, і яго задача — праверыць метаданыя, якія нясе загорнуты blob. Ён атрымлівае гэтыя метаданыя плюс невялікае дакументаванае асяроддзе і мае менш сродкаў, чым хук аўтэнтыфікацыі. Меркаванне, што ён бачыць імёны карыстальнікаў, стан сеанса або зменныя плагіна, — звычайны спосаб дрэнна напісаць гэты хук. Чытайце ўласны раздзел кіраўніцтва хука, а не пазычайце чаканні з іншага хука.

Яго код выхаду — гэта рашэнне: ненулявы вынік адмаўляе кліента, а нулявы дазваляе рукапацісканню працягвацца. Таму палітыка павінна сказаць, што адбываецца, калі метаданыя адсутнічаюць, не разбіраюцца або нечаканыя. Спачатку напішыце шлях адмовы, потым вырашыце, якія значэнні дапушчальныя.

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

Гэтыя два радкі — паверхня палітыкі на серверы: адзін называе ключ загортвання, другі — праграму, якая судзіць кожнага кліента. Усё цікавае жыве ў скрыпце, які заслугоўвае кантролю версій і такога ж прагляду, як любое іншае правіла доступу.

Уліковы запіс, сертыфікат і ключ кантролю адклікаюцца асобна

Ранняе прыняцце кантрольнага канала — не аўтэнтыфікацыя, бо яно адбываецца да праверкі ідэнтычнасці TLS і да любой аўтарызацыі ўліковага запісу. Адключэнне ўліковага запісу, адкліканне сертыфіката і адмова ад ключа кантролю кліента — гэта тры дзеянні з трыма механізмамі. Разгортванне, якое выконвае толькі адно з іх, мае прабел, а не палітыку. Узгадняйце тры свядома і запісвайце, які крок ужывае якія паўнамоцтвы.

Час — другое адрозненне. Зменены спіс прыняцця дзейнічае для новых рукапацісканняў, а ўжо ўсталяваныя сеансы працягваюць ісці, пакуль нешта іх не спыніць. Лічыць запісы ў новым спісе доказам таго, што старыя сеансы скончыліся, — гэта як выдалены кліент застаецца падключаным гадзінамі.

Неўзгодненыя паўнамоцтвы пакідаюць дзве дзіркі, якія лёгка знайсці на практыцы. Уліковы запіс можна адключыць, пакуль яго ключ кантролю ўсё яшчэ адкрывае рукапацісканне, а сертыфікат можна адклікаць, пакуль палітыка метаданых усё яшчэ прымае таго ж кліента. Абодва — адна і тая ж памылка ў розных месцах, бо аператар успрымаў адзін спіс як усе паўнамоцтвы. Пакладзіце тры спісы побач у момант выдалення, і памылка стане бачнай.

Выдача і адкліканне профілю

Выдача — лёгкая палова: стварыце ключ кліента на прымаючым баку, перадайце профіль роўна аднаму ўладальніку, трымайце матэрыял загортвання абмежаваным і запускайце адну і тую ж праграму праверкі на кожным прымаючым серверы. Танны допуск — уласцівасць усёй групы, а не найноўшага хоста. Другі сервер са старэйшым або больш слабым скрыптам моўчкі становіцца самым слабым шляхам у разгортванні.

Адкліканне патрабуе трох крокаў у прадуманым парадку. Адмоўце кліенту ў хуку праверкі, каб новыя рукапацісканні не ўдаваліся, адклічце яго сертыфікат, калі выкарыстоўваецца PKI, і адключыце ўліковы запіс, каб позняй аўтарызацыі не было чаго аўтарызаваць. Затым спыніце сеансы, якія дазволіла старое прыняцце, бо яны не заўважаць ніводнага з трох. Адпрацавайце паслядоўнасць на кліенце, які вы можаце дазволіць сабе зламаць.

Метаданыя ў профілі — гэта ўваход для гэтай палітыкі, а не доказ таго, што кантроль доступу ўжо існуе. Дакумент праектавання OpenVPN 2.6 апісвае аб'екты і мяжу, якую яны праводзяць, а прымус застаецца за аператарам.

Падобныя артыкулы