OpenVPN: tls-ciphersuites در برابر tls-version-min — هرکدام چه چیزی را اعمال می‌کند
فهرست مجموعه‌های TLS 1.3 نسخهٔ پروتکل را محدود نمی‌کند و show-tls فقط پشتیبانی محلی را نشان می‌دهد. سیاست، مجموعه‌ها و نتایج مذاکره‌شده را جداگانه بررسی کنید.
سه واقعیت متفاوت در بیشتر بحث‌های OpenVPN درباره TLS در یک خط جمع می‌شوند: کاری که ساخت کلاینت شما می‌تواند انجام دهد، چیزی که پروفایل اجازه می‌دهد و آنچه نشست واقعاً بر سرش توافق کرده است. فهرست کوتاه مجموعه‌های TLS 1.3 فقط نیمهٔ پاسخ پرسش میانی است و درباره کف نسخهٔ پروتکل چیزی نمی‌گوید. بررسی‌های زیر را به ترتیب انجام دهید و در نخستین بررسی‌ای که برقرار نیست بایستید، زیرا هر بررسی بعدی فرض می‌کند بررسی‌های پیشین حل شده‌اند.
پیش از خواندن هر فهرستی، ساخت را بررسی کنید
یک دستور تنظیمات نمی‌تواند پشتیبانی پروتکلی را به باینری‌ای که آن را ندارد اضافه کند. با بنر نسخه شروع کنید که کتابخانهٔ رمزنگاری کامپایل‌شده را نام می‌برد:
openvpn --versionساخت 2.6 که با OpenSSL پیوند خورده هم tls-cipher و هم tls-ciphersuites را می‌پذیرد. ساخت با mbed TLS اصلاً گزینش مجموعه‌های TLS 1.3 ندارد، و راهنمای 2.6 tls-ciphersuites را گزینه‌ای مخصوص OpenSSL می‌داند. اگر سرور با بک‌اند دیگری بازسازی شود، همان پروفایل می‌تواند رفتارش را تغییر دهد بی‌آنکه یک خط از تنظیمات تغییر کند.
تا اینجا هستید، openvpn --show-tls را اجرا کنید و خروجی را نگه دارید. این همان فهرست موجودی است که بعداً با آن مقایسه می‌کنید، و ثبت آن پیش از آنکه کسی ویرایش پروفایل‌ها را آغاز کند ارزان است.
بنر و فهرست را در تیکت تغییر بنویسید، نه در پنجرهٔ گفتگو. وقتی دو نفر بر سر این اختلاف دارند که آیا کلاینتی شش هفتهٔ دیگر می‌تواند مجموعه‌ای را پیشنهاد دهد، خروجی ثبت‌شده در یک خط آن را روشن می‌کند.
مرزهای نسخه را از فهرست‌های رمز جدا نگه دارید
در راهنمای 2.6 این‌ها سه کنترل‌اند، نه یکی:
tls-cipherسیاست رمز را برای TLS 1.2 و پیش‌تر تعیین می‌کند و به فهرست رمز OpenSSL سپرده می‌شود؛tls-ciphersuitesمجموعه‌های TLS 1.3 را برمی‌گزیند؛tls-version-minوtls-version-maxنسخه‌های پروتکلی را که اتصال می‌تواند به کار ببرد محدود می‌کنند.
پس فهرست مجموعه‌های TLS 1.3 که با دقت هرس شده چیزی را دربارهٔ مجاز بودن هنوز یک نسخهٔ قدیمی‌تر ثابت نمی‌کند. اگر شرط «فقط TLS 1.3» باشد، کف نسخه آن را حمل می‌کند و فهرست مجموعه‌ها تنها گزینه‌ها را درون همان کف تنگ می‌کند:
tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256این جفت دو کار می‌کند. حذف یکی از خط‌ها دیگری را وادار می‌کند کمتر از آنچه فکر می‌کنید اعمال شود، و همین همان شکستی است که کل این بررسی برای گرفتنش وجود دارد.
کانال داده چهارمین کنترل است. data-ciphers رمز متقارن درون تونل را مذاکره می‌کند و نتیجه‌اش دربارهٔ نسخهٔ TLS کانال کنترل چیزی نمی‌گوید. دیدن AES-256-GCM در خلاصهٔ نشست به هیچ روی شاهدی بر TLS 1.3 نیست.
show-tls را به‌عنوان فهرست موجودی محلی بخوانید
--show-tls مجموعه‌هایی را فهرست می‌کند که کتابخانهٔ رمزنگاریِ پیوندخورده با این باینری پشتیبانی می‌کند، به ترتیب ترجیح. این گزارش دروازه نیست. راهنما صریح می‌گوید فهرست از کتابخانهٔ محلی می‌آید، یعنی لپ‌تاپی با OpenSSL 3.x و روتری با ساخت قدیمی‌تر هنگام گفتگو با همان سرور فهرست‌های متفاوتی چاپ می‌کنند.
| Evidence | What it actually describes |
|---|---|
--show-tls output | Capabilities of this client build and its library |
| Profile directives | What this attempt is allowed to offer |
| Session log line | What this one negotiation selected |
فرض کنید کلاینتی مجموعه‌های A، B و C را پشتیبانی می‌کند و یک نشست B را برمی‌گزیند. این هیچ چیزی را دربارهٔ اینکه سرور A یا C را اجازه می‌دهد، یا اینکه B تنها گزینهٔ مجاز آن است، اثبات نمی‌کند. سه ردیف را جدا نگه دارید و بیشتر رشته‌های گیج‌کنندهٔ TLS خودبه‌خود حل می‌شوند.
با این حال نگه داشتن فهرست موجودی ارزش دارد. وقتی نشستی شکست می‌خورد، مقایسهٔ فهرست کتابخانه با فهرست پروفایل نشان می‌دهد آیا کلاینت هیچ شانسی برای پیشنهاد آنچه سرور می‌خواست داشته است. همچنین نشان می‌دهد آیا تغییری در بک‌اند بی‌صدا TLS_CHACHA20_POLY1305_SHA256 را از مجموعهٔ مورد اتکای کلاینت‌های قدیمی‌تر برداشته است — همان نوع رگرسیونی که به‌صورت مشتی کاربر که نمی‌توانند متصل شوند ظاهر می‌شود، در حالی که بقیه چیزی متوجه نمی‌شوند.
از دروازه چیزی بپرسید که بتواند پاسخ دهد
اگر سرویس را مدیریت می‌کنید، تنظیمات مؤثر نمونهٔ در حال اجرا را بررسی کنید نه فایلی روی دیسک. ممکن است OpenVPN با مسیر --config دیگری آغاز شده باشد، شامل‌ها را بکشد، یا از زمان ویرایش دوباره راه‌اندازی نشده باشد. سیاست دیمنِ در حال اجرا همان چیزی است که کلاینت‌ها با آن روبه‌رو می‌شوند.
اگر آن را مدیریت نمی‌کنید، از اپراتور نیازمندی‌های پشتیبانی‌شدهٔ کلاینت یا آزمون پذیرش محدود را بخواهید. تلاش ردشده به‌طور خودکار مجموعهٔ ردشده نیست: کف نسخه، بررسی‌های هویت گواهی مانند remote-cert-tls، یا ناسازگاری tls-auth با tls-crypt می‌تواند تبادل را پیش از آنکه گزینش مجموعه اهمیت یابد پایان دهد. پیش از تغییر فهرست کلاینت، خطای سرور را بخوانید، زیرا «handshake failed» چهار علت متفاوت را می‌پوشاند و تنها یکی از آن‌ها ناسازگاری رمز است.
نشانه‌گیری openssl s_client به سمت درگاه VPN هم پرسش را بازتولید نمی‌کند. کانال کنترل درون قالب‌بندی خود OpenVPN اجرا می‌شود، پس یک کاوش خام TLS پروتکل دیگری را روی درگاهی می‌آزماید که چیز دیگری انتظار دارد. هر نتیجه‌ای از آن دربارهٔ کاوش است، نه تونل.
دو نتیجه را ثبت کنید و آن‌ها را جدا نگه دارید
یک نشست مجاز تازه خطی از کانال کنترل تولید می‌کند که نسخهٔ پروتکل و رمز انتخاب‌شده را نام می‌برد، و خطی جداگانه از کانال داده که رمز تونل را نام می‌برد. هر دو را همراه با نسخهٔ کلاینت و نام پروفایل ثبت کنید و بنویسید کدام نمونهٔ سرور پاسخ داد:
openvpn --config office.ovpn --verb 4 2>&1 | tee session.txtسپس دو خط را از همان فایل بخوانید نه از حافظه. این جفت شاهد است؛ یک نام مجموعه به‌تنهایی ترجیح است، و مرز نسخه بیانیه‌ای جداگانه دربارهٔ آن چیزی است که سرور رد می‌کند.
بررسی‌ها را به این ترتیب انجام دهید. ساخت و بک‌اند را با --version تأیید کنید. پیش از هر تغییری --show-tls را ثبت کنید. کف نسخهٔ لازم را جدا از فهرست مجموعه‌ها بیان کنید. سیاست مؤثر نمونهٔ در حال اجرا را با مالک آن تأیید کنید. یک نشست مجاز و، اگر طرح اجازه دهد، یک تلاش ردشده با نسخهٔ قدیمی‌تر را مشاهده کنید. نتایج کانال کنترل و کانال داده را به‌عنوان یافته‌های جداگانه ثبت کنید.
اگر کلاینت لازم نمی‌تواند حداقل تازه‌ای را برآورده کند، آن تصمیم مهاجرت یا استثنا را صریح بگیرید، نه اینکه بی‌صدا قاعده‌ای پذیرشی نامرتبط را پایین بیاورید تا عرضه تمام‌شده به نظر برسد.