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