آیا گواهی RSA می‌تواند با dh none در OpenVPN کار کند؟

اینجا پیکربندی سروری است که در کنار گواهی‌ای با عنوان RSA، عبارت dh none را می‌گوید، به‌همراه این سوءظن آزاردهنده که یکی از این دو باید اشتباه باشد. هیچ چیز اشتباه نیست. گواهی امضا و احراز هویت می‌کند؛ تبادل کلید یک راز مشترک برقرار می‌کند. این‌ها دو کار متفاوت در یک دست‌دادن هستند، و TLS به گواهی RSA اجازه می‌دهد دست‌دادنی را احراز هویت کند که از توافق موقت روی خم بیضوی استفاده می‌کند.

سردرگمی معمولاً همراه یک راهنمای مهاجرت می‌آید. می‌گوید فایل پارامترهای DH را با dh none جایگزین کنید، خواننده متوجه می‌شود گواهی، گواهی خم بیضوی نیست، و این دو واقعیت تناقض تلقی می‌شوند.

چرا این دو تنظیم مرتبط به نظر می‌رسند

پیکربندی قدیمی‌تر OpenVPN فایل پارامترهای DH را می‌خواست، چون Diffie-Hellman در میدان متناهی به پارامترهای دامنه‌ای نیاز دارد که هر دو طرف بر آن توافق کنند. دستور dh به همان فایل اشاره می‌کرد. وقتی یک استقرار به ECDH می‌رود، پارامترها به‌جای آن از یک خم نام‌دار می‌آیند و فایل دیگر لازم نیست، و این همان چیزی است که dh none بیان می‌کند.

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

نام‌گذاری هم‌پوشانی را بدتر می‌کند. خم بیضوی هم در نام مجموعه‌های ECDHE و هم ECDSA ظاهر می‌شود، بنابراین آسان است فرض کنیم هر اتصالی که خم را ذکر می‌کند باید گواهی خم داشته باشد. این‌طور نیست.

چگونه نام یک مجموعه TLS 1.2 را درست بخوانیم

ECDHE-RSA-AES256-GCM-SHA384 را در نظر بگیرید. نشانه نخست خانواده تبادل کلید است: Diffie-Hellman موقت روی خم بیضوی. دومی خانواده احراز هویت است: RSA. بقیه حفاظت رکورد و هشی را که در دست‌دادن استفاده می‌شود توصیف می‌کند.

مجموعه ECDHE-ECDSA همان خانواده تبادل کلید را با روش احراز هویت متفاوتی به کار می‌برد، پس به گواهی خم بیضوی نیاز دارد. مجموعه DHE-RSA از Diffie-Hellman موقت در میدان متناهی با احراز هویت RSA استفاده می‌کند، و آن یکی واقعاً به پارامترهای DH نیاز دارد.

نام مجموعه را از چپ به راست بخوانید و هر بخش را به کار خودش نسبت دهید. وقتی نشانه‌ها جدا شوند، پرسش از «آیا گواهی من با dh none مطابقت دارد» به «آیا سرور من مجموعه‌ای را مجاز می‌داند که تبادل کلیدش به فایل DH نیاز ندارد» تغییر می‌کند.

dh none در واقع چه چیزی را غیرفعال می‌کند

dh none به سرور می‌گوید فایل پارامترهای DH میدان متناهی را بارگذاری نکند. این دستور احراز هویت، اعتبارسنجی گواهی یا خود TLS را غیرفعال نمی‌کند. اما لازم می‌داند تبادل کلید توافق‌شده به آن پارامترها نیاز نداشته باشد، که در عمل یعنی یک مجموعه ECDHE یا یک دست‌دادن TLS 1.3.

خرابی از همین الزام می‌آید. اگر سیاست رمزنگاری TLS سرور به مجموعه‌های DHE محدود باشد، یا کلاینتی فقط همان‌ها را پیشنهاد دهد، حذف فایل پارامترها هیچ روش قابل استفاده‌ای برای تبادل کلید باقی نمی‌گذارد و دست‌دادن شکست می‌خورد. خطا معمولاً در دست‌دادن کانال کنترل و پیش از هر احراز هویت کاربر ظاهر می‌شود. پیش از سرزنش فایل غایب، فهرست رمزها را بخوانید.

در سمت خم بیضوی، خم را پیکربندی TLS سرور انتخاب می‌کند، و OpenVPN در شاخه‌های قدیمی‌تر گزینه‌ای برای انتخاب آن ارائه می‌دهد. TLS 1.3 مذاکره گروه را درون پروتکل انجام می‌دهد و اصلاً به فایل DH مراجعه نمی‌کند.

dh none به‌خودی‌خود یک کاهش امنیتی نیست. قدرت تبادل سپس به خم و مجموعه‌ای بستگی دارد که واقعاً مذاکره می‌شوند، به همین دلیل گام بعدی نگاه کردن به انتخاب طرف‌هاست، نه به فایل غایب.

تأیید مذاکره پیش از ویرایش

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

اگر TLS 1.2 را با مجموعه ECDHE-RSA و گواهی RSA نشان دهد، ترکیب دقیقاً همان چیزی است که dh none انتظار دارد و چیزی برای تعمیر نیست. اگر مجموعه DHE یا شکست دست‌دادن بدون رمز مشترک نشان دهد، اصلاح در سیاست رمز یا توانایی کلاینت است، نه در گواهی.

قدیمی‌ترین کلاینتی را که قصد پشتیبانی از آن را دارید آزمایش کنید، چون کلاینت کنونی ممکن است TLS 1.3 را مذاکره کند در حالی که کلاینت قدیمی‌تر به مجموعه‌های TLS 1.2 محدود است. اگر قدیمی‌ترین کلاینت هیچ هم‌پوشانی نداشته باشد، یا مجموعه‌های مجاز را گسترده کنید یا آن نقطه پایانی را ارتقا دهید.

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

فهرست بررسی: آیا گواهی RSA است، آیا مجموعه ECDHE مجاز است، آیا گزارش همان مجموعه را نشان می‌دهد، و آیا قدیمی‌ترین کلاینت پشتیبانی‌شده هم آن را مذاکره می‌کند؟ اگر هر چهار پاسخ بله است، dh none کار خود را انجام می‌دهد.