آیا یک دستدادن ناموفق VPN واقعاً حملهٔ تنزل است؟
حملات تنزل وجود دارند، اما بیشتر دستدادنهای ناموفق ناسازگاری پیشنهاد، مسیر بد یا نمایهٔ منقضی هستند. اول بررسی کنید چه چیزی مذاکره شده است.
دستدادنی که با خطا تمام میشود تا وقتی پیام را نگاه نکنید شبیه حمله است، و بیشتر وقتها موضوع حساب است: پیشنهاد مشترکی نیست، گواهی منقضی شده یا بستهای که هرگز نرسید. حملهٔ تنزل چیز مشخصی است: مهاجمی که هر دو سر را به رفتاری ضعیفتر از آنچه انتخاب میکردند سوق میدهد، و شواهد متفاوتی بر جای میگذارد. اگر هر شکست را سوءنیت بدانید به دنبال قربانیای میروید که شاید وجود نداشته باشد، و اگر تنزل واقعی را باگ پیکربندی بدانید نتیجهٔ ضعیفتر سر جای خود میماند. این دو خطا هزینهٔ متفاوتی دارند و فقط یکی از آنها ارزان اصلاح میشود.
حملهٔ تنزل واقعاً چه چیزی را تغییر میدهد
هدف شکستن رمز و حدس زدن کلید نیست. هدف تأثیر بر مذاکره است تا هر دو طرف روی نسخهٔ قدیمیتر یا الگوریتم ضعیفتری که مهاجم از عهدهٔ آن برمیآید بمانند، یا یک طرف باور کند طرف دیگر فقط همان را پشتیبانی میکند.
آنچه تغییر میکند توافق است، نه احراز هویت. اگر مهاجم بتواند پیشنهاد را بدون شناسایی شدن تغییر دهد، همتاها همچنان میتوانند دستدادن را کامل کنند و یکدیگر را احراز هویت کنند، اما با پارامترهایی که مهاجم ترجیح میدهد. به همین دلیل پرسش جالب این است که آیا خود مذاکره زیر پوشش حفاظت یکپارچگی است.
چرا خود مذاکره باید احراز هویت شود
TLS 1.3 این حفاظت را صریح میکند. کارخواهی که نسخهٔ جدیدتر را پیشنهاد کرده میتواند سروری را که بیصدا عقب نشسته تشخیص دهد، زیرا مقدار تصادفی سرور هنگام مذاکره روی 1.2 یا پایینتر الگوی ثابتی دارد و کارخواه موظف است با دیدن آن قطع کند. کل رونوشت نیز با پیامهای پایانی پوشش داده میشود، پس تغییر در هر جای مذاکره بعداً شکست میخورد نه اینکه بیصدا بگذرد.
نسخههای قدیمیتر پروتکل داستانهای ضعیفتری داشتند و دقیقاً به همین دلیل قواعد عقبنشینی اهمیت دارند. یک نقطهٔ پایانی TLS 1.0 در همان پیکربندی حملهٔ تنزل نیست؛ نتیجهای مجاز است که خودتان انتخاب کردید اجازه دهید. تمایز در این است که نتیجهٔ ضعیفتر از تصمیمی محافظتشده آمده یا از مسیری نامحافظتشده که واسطهای میتوانست بر آن اثر بگذارد. وقتی اینطور بیانش کنید، بیشتر رخدادها به پرسش پیکربندی تبدیل میشوند.
IKEv2 رفتار متفاوتی دارد اما بر همان ایده استوار است. پیشنهاد در تبادلی حمل میشود که بعداً هر دو همتا را احراز هویت میکند، پس جعبهٔ میانیای که الگوریتمها را بازنویسی میکند احراز هویت را میشکند نه اینکه آن را هدایت کند. کانال کنترل OpenVPN مذاکرهٔ خود را با TLS محافظت میکند و سپس از همان کانال برای توافق بر رمزهای کانال داده استفاده میکند، به همین دلیل خط گزارش کانال کنترل خط جالب است.
سازگاری پیکربندیشده حمله نیست
مدیر میتواند آگاهانه گزینههای قدیمیتر را برای پشتیبانی از کلاینتی مستند مجاز کند و آن تصمیم در پیکربندی دیده میشود. مهاجم نمیتواند چنین پیکربندیای بسازد؛ فقط میتواند مسیری را بهرهبرداری کند که به او اجازهٔ اثرگذاری بر پیشنهاد را میدهد.
تعمیر خطرناک آن است که شاهد تفاوت را حذف میکند. فعال کردن هر گزینهٔ قدیمی، خاموش کردن بررسی گواهی یا پذیرفتن هر رمزی برای محو شدن یک خطا، آنچه نقطهٔ پایانی میپذیرد را گستردهتر میکند و بررسیهایی را که نتیجهٔ ضعیفتر را گزارش میکردند حذف میکند.
اگر باید یک گزینهٔ قدیمی را نگه دارید، دلیل و کلاینت را در توضیح پیکربندی بنویسید، سپس گزینه را به نمایهای که به آن نیاز دارد محدود کنید. استثنای سازگاری محدود به یک شنونده قابل حسابرسی است؛ آنکه سراسری اعمال شود فقط یک پیشفرض ضعیفتر است که هیچکس یادش نیست آن را انتخاب کرده.
پیش از نامگذاری علت، شکست را بخوانید
رشتهٔ دقیق خطا، نسخههای کلاینت و سرور و زمان را پیش از هر تغییری نگه دارید. سپس دستهبندی کنید: آیا همتاها بر سر پیشنهاد اختلاف داشتند، مسیر بسته شکست خورد، یا یک طرف پارامتری را رد کرد که زمانی میپذیرفت؟
ناسازگاری پیشنهاد معمولاً نسخهها یا الگوریتمهای مقصر را نام میبرد و هر بار در همان نقطه شکست میخورد. مشکل مسیریابی یا MTU متوقف میشود یا به پایان زمان میرسد و اغلب با شبکه تغییر میکند. گواهی منقضی خطای بررسی تولید میکند نه خطای مذاکره.
هیچکدام از اینها شاهد مهاجم نیست. نسبت دادن علت بدخواهانه در نخستین شکست همان خطاست، زیرا باگ قطعیای را پنهان میکند که فردا دوباره شکست میخورد.
تأیید کنید واقعاً چه چیزی انتخاب شد
پس از هر اصلاحی، نتیجهٔ مذاکرهشده را بخوانید نه اینکه به بالا آمدن اتصال اعتماد کنید. اتصالی که به دلیل حذف بررسی موفق میشود همان نتیجهای است که میخواستید از آن دوری کنید. دو فرمان زیر نسخه و رمز انتخابشده برای یک نقطهٔ پایانی با TLS را نشان میدهد، بههمراه خط کانال کنترل از گزارش یک OpenVPN سرور.
openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5نتیجه را با پیکربندیای که در نظر داشتید مقایسه کنید، نه با آنچه اکنون متصل میشود. اگر نسخهٔ انتخابشده از حداقل مجاز قدیمیتر است، نمایه یا فهرست عقبنشینی جای بررسی است و پاسخ اصلاح همان فهرست است، نه اعلام حمله و بازسازی همهچیز پیرامون آن.