OpenVPN tls-crypt-v2: што робяць ключ кліента і загорнуты blob
Профіль tls-crypt-v2 змяшчае ключ кантролю кліента і загорнутую копію, якую можа адкрыць толькі сервер. Трымайце кожны аб'ект і кожны крок адклікання асобна.
Уставіць профіль tls-crypt-v2 у заяўку выглядае бясшкодна, пакуль не палічыш, што змяшчае файл. Ключ кантрольнага канала кліента стаіць побач з шыфраванай копіяй таго ж ключа, а трэці аб'ект — ключ загортвання — ніколі не пакідае сервер, што прымае. Гэтыя тры адказваюць на розныя пытанні пра захоўванне, абмен і адкліканне. Іх падзел здымае большасць спрэчак пра палітыку яшчэ да іх пачатку.
Што профіль насамрэч змяшчае
Кліенцкая палова tls-crypt-v2 — гэта ключ плюс загорнутая яго копія. Кліент выкарыстоўвае звычайны ключ для абароны кантрольнага канала і перадае загорнутую копію серверу падчас наладжвання, так што сервер аднаўляе той самы ключ, не захоўваючы тэкставую копію для кожнага кліента. Ключ загортвання робіць гэтае аднаўленне магчымым і належыць толькі прымаючаму боку. Усё ніжэй вынікае з таго, дзе жывуць гэтыя тры аб'екты.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone 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 апісвае аб'екты і мяжу, якую яны праводзяць, а прымус застаецца за аператарам.