Журнал OpenVPN: шыфр кіраўнічага канала супраць шыфра канала даных

Радок журнала, у якім названы DHE-RSA-AES256-SHA, не з'яўляецца зводкай усяго злучэння. Ён належыць да TLS-рукапаціску, якое абараняе кіраўнічы канал, а трафік унутры тунеля можа быць зашыфраваны зусім інакш. Падаваць яго як шыфр даных VPN — памылка, якой трэба пазбягаць.

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

Два вынікі, два пытанні

Кіраўнічы канал пераносіць рукапаціск і кіраўнічыя паведамленні паміж бакамі. Яго шыфр выбірае стек TLS, таму імя ідзе за канвенцыямі TLS. Канал даных пераносіць карыстальніцкі трафік, і яго наладжвае ўласнае ўзгадненне шыфра OpenVPN.

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

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

Разбярыце імя набору TLS у яго ўласным кантэксце

У гістарычным імені ў стылі OpenSSL, такім як DHE-RSA-AES256-SHA, кожны кампанент апісвае асобнае рашэнне. DHE — гэта эфемернае ўзгадненне ключоў Дыфі — Хелмана, RSA — метад аўтэнтыфікацыі, AES256 — AES-256 у рэжыме CBC для запісаў TLS, а SHA — MAC запісу на аснове SHA-1.

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

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

Прачытайце вынік канала даных для пераноснага трафіку

Для пераноснага трафіку чытайце радок канала даных з той самай сесіі. Спіс data-ciphers у канфігурацыі — гэта дазволены набор, а не доказ, што быў узгоджаны пэўны алгарытм. Журнал фіксуе выбар; канфігурацыя пералічвае меню.

Шыфр AEAD, напрыклад AES-GCM, мае ўласную праверку цэласнасці, таму асобны HMAC канала даных не ўваходзіць у гэты шлях.

Дырэктыва auth не абнаўляе TLS, сертыфікаты ці шыфр даных. Яна выбірае дайджэст для тых частак пратакола, якія яшчэ яго выкарыстоўваюць, а з шыфрам даных AEAD асобнага HMAC даных наладжваць не трэба.

Трымайце праверкі ідэнтычнасці па-за вынікам шыфра

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

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

Запішыце ўзгоджаныя вынікі бягучай сесіі

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

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