خطای رمزنگاری ضعیف vpnc: سیاست دروازه یا تعمیر رومیزی؟

دو تعمیر به یک اندازه سریع به نظر می‌رسند وقتی یک اتصال قدیمی vpnc از بالا آمدن امتناع می‌کند: پرچم رمزنگاری ضعیف قدیمی را پاس کنید، یا اسکریپت پوششی را اضافه کنید که آن را به جای شما می‌افزاید. این دو معادل نیستند، زیرا یکی سیاست یک پروفایل را تغییر می‌دهد و دیگری رفتار هر برنامه‌ای را که آن مسیر را فراخوانی می‌کند. پرسش اول این است که آیا دروازه هنوز پیشنهاد ضعیفی ارائه می‌دهد، و دومی این است که چه کسی مجاز به پذیرش آن است. بقیه چیزها از این دو پاسخ ناشی می‌شود.

دو تعمیر با دامنه تأثیر بسیار متفاوت

تغییر در سطح پروفایل به یک اتصال، یک مالک و یک تاریخ انقضا دست می‌زند. جایگزینی باینری نصب‌شده به هر فرانت‌اند روی دستگاه دست می‌زند، از جمله اپلت رومیزی که همکاری برای پروفایل دروازه‌ای کاملاً متفاوت استفاده می‌کند. اسکریپت پوششی تغییر را از هر کسی که شش ماه بعد میزبان را اشکال‌زدایی کند نیز پنهان می‌کند.

بررسی بسته اولین قربانی است: فایلی در /usr/sbin/vpnc که دیگر با بسته‌اش مطابقت ندارد، یک به‌روزرسانی امنیتی معمول را به یک تحقیق تبدیل می‌کند. سپس به‌روزرسانی‌ها یا بی‌صدا روی پوشش می‌نویسند یا از اعمال امتناع می‌کنند، بسته به اینکه مدیر بسته با فایل‌های تغییر‌یافته چگونه رفتار می‌کند. هیچ‌یک از این نتایج در گزارش اتصال ظاهر نمی‌شود، به همین دلیل رویکرد پوششی تا اولین حادثه جذاب می‌ماند. یک خط در پروفایل بسیار آسان‌تر از یک باینری که هیچ‌کس به یاد نمی‌آورد جایگزینش کرده پیدا و حذف می‌شود.

کلید منسوخ واقعاً چه می‌کند

راهنمای vpnc گزینه تک‌DES را به سود تنظیم رمزنگاری ضعیف منسوخ می‌داند و گزینه جداگانه‌ای را مستند می‌کند که اصلاً هیچ رمزنگاری برای ترافیک داده مجاز نمی‌داند. اینها امتیازهای متفاوت با پیامدهای متفاوت هستند. هیچ‌کدام باعث نمی‌شود یک دروازه مدرن درباره چیزی که دیگر ارائه نمی‌دهد مذاکره کند.

قبل از انتخاب تعمیر، مرحله شکست را بخوانید. پیشنهاد ردشده و گذرواژه ردشده پیام‌های فرانت‌اند مشابه اما شواهد کاملاً متفاوت تولید می‌کنند.

استثنای محدود کجا جای دارد

اگر سازمانی آگاهانه یک همتای قدیمی را برای دوره‌ای محدود بپذیرد، استثنا در پروفایل همان همتا جای دارد، با یک مالک، یک تاریخ بازبینی و مسیری برای مهاجرت به پروتکل پشتیبانی‌شده. نگه داشتن آن بیرون از مسیر سراسری همان تمام معنای محدود نامیدن آن است.

از مالک دروازه بخواهید تأیید کند که همتا هنوز کدام الگوریتم‌ها را پیشنهاد می‌دهد و چه چیزی جایگزین آن می‌شود. پرچم کلاینت نمی‌تواند پیشنهادی را که سرور دیگر نمی‌فرستد تعمیر کند، و مهاجرت سروری که هیچ‌کس برنامه‌ریزی نکرده از راه‌حل موقت بیشتر عمر می‌کند. تاریخ بازبینی را در همان تیکت استثنا بگذارید تا امتیاز منقضی شود نه اینکه دائمی گردد.

مذاکره را بررسی کنید، نه فقط نماد سبز را

شواهدی جمع کنید که مرحله را مشخص کند نه حال‌وهوای گفتگو را. دستورهای زیر فقط خواندنی هستند و دو مورد اول نشان می‌دهند کدام پیکربندی و نسخه واقعاً در کار است.

vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf

دستور سوم فایل‌هایی را گزارش می‌کند که دیگر با بسته مطابقت ندارند، و پوشش فراموش‌شده این‌گونه خود را اعلام می‌کند. دستور چهارم امتیازهایی را نشان می‌دهد که پروفایل حمل می‌کند، تا استثنا نتواند بی‌صدا از طریق فایلی کپی‌شده به پروفایل دوم سرایت کند. هر دو را قبل و بعد از تغییر اجرا کنید و خروجی را کنار پروفایل اتصال نگه دارید نه در پنجره چت.

خروجی اشکال‌زدایی را تا زمانی که کسی آن را نخوانده از تیکت‌ها بیرون نگه دارید، زیرا راهنما هشدار می‌دهد که بالاترین سطح اشکال‌زدایی داده‌های احراز هویت از جمله گذرواژه‌ها را بیرون می‌ریزد. معیار پذیرش یک توافق مجاز و پشتیبانی‌شده بین کلاینت و دروازه است، نه یک آیتم منو که سرانجام سبز می‌شود. اگر همتا فقط الگوریتمی خراب ارائه دهد، نتیجه صادقانه یک استثنا با تاریخ پایان یا پروتکل جایگزین است و آن تصمیم متعلق به کسی است که دروازه را دارد. ثبت تصمیم همان تفاوت بین یک استثنای مدیریت‌شده و یک تغییر سیاست تصادفی است.