Трасаванне пакетаў кіравання OpenVPN: tls-auth да TLS

Збой tls-auth звычайна паведамляецца як праблема рукапаціскання, хаця ёй ніколі не быў. HMAC правяраецца на кантрольным пакеце да пачатку любой апрацоўкі TLS, таму неадпаведны ключ або кірунак дае збой, які выглядае як праблема сертыфіката і вырашаецца на два ўзроўні раней. Разгляд канверта як асобнага аб'екта робіць дыягностыку кароткай: прачытайце палі, пераканайцеся, што праверка спрацоўвае рана, затым параўнайце тры рэчы, на якіх павінны сысціся абодва бакі.

Чытайце канверт у тым парадку, у якім ён будуецца

Кантрольны пакет нясе ідэнтыфікатар сеанса, неабавязковы HMAC tls-auth, звесткі аб паўторы і пацверджанні, а таксама надзейны ідэнтыфікатар паведамлення, а пасля гэтага ідзе карысная нагрузка тыпу паведамлення. Калі паведамленне з'яўляецца паведамленнем рукапаціскання, нагрузка аказваецца шыфратэкстам TLS. Уся сувязь менавіта такая: матэрыял TLS падарожнічае ўнутры паведамлення, якое канверт ужо абараняе. Глядзіце Даведнік па сеткавым пратаколе OpenVPN пералічвае палі кантрольнага канала менавіта ў такім парадку.

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

Трымайце гэтае групаванне як паняцце. Гэта не дыяграма парадку байтаў, і яго недастаткова, каб вылічыць тэг, бо палі, якія ўваходзяць у HMAC, залежаць ад рэалізацыі, версіі і рэжыму.

Пакажыце, што праверка спрацоўвае да рукапаціскання

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

Павялічце шматслоўнасць дэмана і назірайце за кантрольным каналам, а не за прыладай tun:

openvpn --config /etc/openvpn/server.conf --verb 6

Вы шукаеце збой праверкі HMAC кантрольнага канала, які паведамляецца на ўзроўні пакета, да любога папярэджання TLS. Папярэджанне TLS у журнале азначае, што канверт быў прыняты і збой перамясціўся ўнутр, а гэта іншае расследаванне з іншым рашэннем.

Апрацоўка кірунку таксама тут. Калі статычны файл ключа выкарыстоўваецца з tls-auth, два бакі бяруць процілеглыя кірункі ключа, і пратакол выкарыстоўвае гэтае раздзяленне, каб перахоплены пакет нельга было адбіць назад да адпраўніка. Перавернуты кірунак пакідае ключ аднолькавым і ўсё роўна правальвае кожны пакет. Мяняйце па адным баку за раз, затым перазапусціце абодва дэманы, каб пара загружалася разам.

Звядзіце ключ, кірунак і digest на абодвух баках

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Стварайце агульны сакрэт інструментам, а не рэдактарам, і трымайце правы жорсткімі:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

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

Аднаўляйце тэг толькі з рэальнага фармату

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

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

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

Адкот неадпаведнасці без зняцця абароны

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

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

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