DES در برابر 3DES در VPN: چرا هر دو ارتقای اشتباهی هستند
مقایسهٔ مفید نه DES در برابر 3DES، بلکه یک الگوریتم بازنشسته در برابر یک الگوریتم نگهداریشده است. ببینید چه چیزی هنوز به رمزنگاری قدیمی نیاز دارد، سپس آن را محدود یا حذف کنید.
هر دو رمزنگاری منسوخ شدهاند و هیچکدام هدف درستی برای ترافیک جدید نیستند. مقایسهٔ مفید نه DES در برابر 3DES است؛ بلکه یک الگوریتم بازنشسته در برابر یک الگوریتم نگهداریشده است. اگر دروازهای هنوز یکی از آن دو را ارائه میدهد، کار این است که بفهمید چه چیزی به آن نیاز دارد و آن نیاز را بردارید، نه اینکه قویترِ دو بنبست را انتخاب کنید.
مقایسهای که مردم هنوز دنبالش میگردند اشتباه است
پاسخهایی که در دههٔ 2000 نوشته شدهاند DES را با DES سهگانه مقایسه میکنند و نتیجه میگیرند که DES سهگانه قویتر است. آن زمان معقول بود و اکنون بیفایده است، چون هر دو برای حفاظت از ترافیک جدید بازنشسته شدهاند و انتخاب میان آنها انتخاب میان دو بنبست است.
NIST در سال 2005 استاندارد DES را پس گرفت و توصیهٔ TDEA آن در ژانویهٔ 2024 پس گرفته شد، پس از آنکه مهلت بهکارگیری TDEA برای حفاظت رمزنگاری جدید در پایان 2023 گذشت. این تاریخها یک گذار را توصیف میکنند، نه یک رتبهبندی. یک نشست کوتاه یا پیام کمارزش پرسش را دوباره باز نمیکند، چون وضعیت الگوریتم به این بستگی ندارد که کلید چه مدت استفاده شود.
تمدید کلید یک کنترل جداگانه است و تأیید را بازنمیگرداند.
مذاکره را از مسیر داده جدا کنید
پروتکلهای VPN حفاظت را در بیش از یک جا مذاکره میکنند. ممکن است کانال کنترل یک مجموعه را به کار ببرد در حالی که دادهٔ حملشده مجموعهٔ دیگری را، و فهرست پیشنهادها فقط میگوید همتا چه چیزی را میپذیرد. نتیجهٔ مذاکرهشده را بخوانید، نه پیشنهاد را. این تمایز یک سردرگمی رایج را توضیح میدهد: دروازهای هنوز یک الگوریتم قدیمی را فهرست میکند و اپراتور گمان میکند در حال استفاده است، در حالی که ممکن است پیشنهاد شود و هرگز انتخاب نشود، یا فقط برای یک همتای قدیمی انتخاب شود.
در یک دروازهٔ IPsec خروجی مرتبط، انجمن امنیتی است؛ در OpenVPN این رمزنگاری و تنظیمات TLS در گزارش اتصال است. هر دو میگویند چه چیزی انتخاب شده است. هیچیک با وجود یک گزینهٔ قدیمی در پروندهٔ پیکربندی اثبات نمیشود.
اگر نتیجهٔ مذاکرهشده را نمیبینید، نمیتوانید ادعا کنید که رمزنگاری بازنشسته شده است.
مؤلفهای را پیدا کنید که هنوز آن را میخواهد
نیازهای قدیمی از سه جا میآیند: یک کلاینت قدیمی که چیز بهتری ارائه نمیدهد، یک سیاست دروازه که هنوز الگوریتم را فهرست میکند، و دستگاهی که فقط پروتکل قدیمی را میفهمد. هر یک راهحل متفاوتی دارد. پیش از فعالکردن یک ارائهدهندهٔ سازگاری، از صاحب آن محدودیت بپرسید کدامیک است، چون فعالکردن آن بر هر همتایی که متصل میشود اثر میگذارد.
برای یک دستگاه که هنوز جایگزین نمیشود، یک دروازهٔ نگهداریشده جلوی آن بگذارید و محدود کنید که آن مرز چه چیزی را حمل میکند. این رمزنگاری قدیمی را مهار میکند بیآنکه هر کاربر دور را وادار به ارثبردن آن کند.
مهار کردن یک وصله نیست و میزبان قدیمی را قابل اعتماد نمیکند.
با همان بررسیهایی که دارید مهاجرت کنید
مهاجرت زمانی تمام میشود که همتاهای موردنظر با نمایهٔ نگهداریشده متصل شوند، مجموعهٔ مذاکرهشده همانی باشد که انتظار داشتید، و برنامه کار کند. راستیآزمایی هویت سرور و بررسیهای حساب را در تمام مدت حفظ کنید؛ تغییر رمزنگاری دلیلی برای سستکردن آنها نیست.
openvpn --version
openssl ciphers -v 'DEFAULT:!DES:!3DES'
نسخههای کلاینت و دروازه را کنار نتیجهٔ مذاکرهشده ثبت کنید تا بازبینی بعدی بتواند بگوید واقعاً چه چیزی تغییر کرده است.
مجوز قدیمی را از طریق صاحبش بازنشسته کنید، سپس تأیید کنید که همتایی که فقط الگوریتم بازنشسته را ارائه میدهد اکنون رد میشود. مهاجرتی که گزینهٔ قدیمی را فعال نگه دارد، مهاجرتی است که رخ نداده است. شاهد رد شدن را همراه سابقهٔ تغییر نگه دارید، چون ممیزی بعدی خواهد پرسید از کجا میدانید، و یک خط پیکربندی حذفشده شاهد ضعیفتری از یک رد ثبتشده است. تاریخ آزمون و هویت همتا را در همان حال که نشست تازه است به آن سابقه بیفزایید.
دادهٔ تاریخی مسئلهٔ دیگری است
خواندن یک بایگانی که سالها پیش محافظت شده ممکن است بهطور مشروع به الگوریتم قدیمی نیاز داشته باشد. این رمزگشایی مواد موجود است و همان کار حفاظت از ترافیک جدید نیست.
چنین کاری را روی میزبانی جدا با هدف مستند و فهرست کوتاهی از کسانی که اجازهٔ اجرای آن را دارند نگه دارید.
این تمایز مهم است چون تنها دلیل صادقانه برای در دسترس نگهداشتن یک رمزنگاری بازنشسته است. یک ابزار محدود را توجیه میکند، نه هرگز یک خط دائمی در یک نمایهٔ عمومی VPN.