Якія пакеты OpenVPN абараняе дайджэст auth?
Опцыя auth ахоплівае менш, чым падказвае профіль. Разбярыце канал, выпадак AEAD і абарону кіравальнага канала, перш чым задаваць палітыку дайджэста.
Большасць спрэчак пра дайджэсты OpenVPN пачынаецца з няправільнага пакета. Чытаць auth SHA256 як «прымаць толькі партнёраў, якія прапануюць SHA256» — першае, што трэба адвыкнуць рабіць. Опцыя называе дайджэст для пэўных пакетаў, і якія гэта пакеты, залежыць ад канала і ад таго, ці гэты канал AEAD. Прайдзіце чатыры пытанні ніжэй па парадку; кожнае звужае, што налада можа значыць у вашым разгортванні.
Назвіце канал, які налада павінна абараняць
OpenVPN мае кіравальны канал, які нясе трафік рукапаціскання TLS, і канал даных, які нясе карысную нагрузку тунеля. Дайджэст auth мае ролю ў абодвух, але не аднолькавую, і профіль рэдка робіць розніцу бачнай. Запішыце, які з двух вы хочаце абмежаваць, перш чым кранаць файл канфігурацыі.
Табліца ніжэй — кароткая версія таго, як тая ж опцыя трапляе ў кожны кантэкст.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Праверце, ці канал даных AEAD, перш чым спадзявацца на гэта
Калі ўзгоднены шыфр даных — AES-GCM або CHACHA20-POLY1305, канал даных аўтэнтыфікуе сам сябе, і асобны дайджэст не выконвае той працы, якую вы, магчыма, уяўляеце. Абодва — канструкцыі AEAD, таму цэласнасць ствараецца той жа аперацыяй, што шыфруе нагрузку. Гэта не паніжэнне ўзроўню, але гэта значыць, што палітыка, абгрунтаваная як «кожны пакет даных — HMAC-SHA256», фактычна памылковая на гэтым тунелі. Пацвердзіце ўзгодненае значэнне ў журнале сервера або вывадзе стану кліента, перш чым перапісваць палітыку.
Правярайце шыфр, які быў фактычна ўзгоднены, а не спіс у профілі, бо ўзгадненне можа трапіць на іншага члена набору. data-ciphers AES-256-GCM:AES-128-GCM — гэта спіс узгаднення, і абодва запісы AEAD, таму ні адзін з іх не спажывае дайджэст auth для абароны нагрузкі.
Разглядайце абарону кіравальнага канала як асобнае рашэнне
tls-auth дадае HMAC да пакетаў кіравальнага канала і бярэ свой дайджэст з налады auth, таму тунель AEAD усё яшчэ можа мець асэнсаваны дайджэст. tls-crypt — іншая схема з уласнай фіксаванай абаронай, таму не думайце, што яна наследуе ўсе ўласцівасці tls-auth. Чытайце дакументацыю для абранага механізма, а не пераносьце здагадкі паміж імі.
Два бакі павінны таксама дамовіцца пра схему і пра кірунак ключа. Дайджэст, які супадае, але файл ключа, ужыты ў няправільным кірунку, дае рукапацісканне, якое правальваецца па прычынах, якія налада дайджэста не можа патлумачыць.
Трымайце auth асобна ад узгаднення шыфраў і сертыфікатаў
Тры налады пастаянна блытаюць: дайджэст auth, спіс шыфраў даных і алгарытм подпісу сертыфіката. Змена першай не перавыдае сертыфікат, не выбірае яго дайджэст подпісу і не стварае метад «карыстальнік-пароль». Вызначэнні опцый пратакола ў крыніцах OpenVPN 2.6 апісваюць кожную ў сваім раздзеле, што служыць карысным напамінам: гэта незалежныя ручкі.
Калі партнёр адмаўляецца падключацца пасля змены дайджэста, прычына звычайна ў неадпаведнасці ў адной з дзвюх іншых налад. Прачытайце абодва канцы, перш чым змяняць любы з іх.
Запішыце палітыку і параўнайце яе з працоўнымі канфігурацыямі
Заява на ўзроўні флоту павінна называць дазволеныя рэжымы канала даных і абраную абарону кіравальнага канала яўна, у адным сказе. Гэты сказ праверачны; «мы выкарыстоўваем SHA256» — не. Затым параўнайце яго з дзейнымі профілямі сервера і кліента, а не з шаблонам у рэпазітары.
Завяршыце запісам таго, што кожны тунель фактычна ўзгадніў і які механізм аўтэнтыфікаваў яго пакеты. Бачны радок auth у профілі — доказ толькі намеру канфігурацыі, а намер — самая таннае частка праверкі.