خطای رمز TLS در OpenVPN: نخست هر دو طرف را مقایسه کنید

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

اگر این ترتیب را اشتباه بروید، ممکن است یک ساعت را صرف افزودن یک نام AES به فهرستی کنید که هرگز به آن مراجعه نشده است.

دو فهرست رمز، و تنها یکی دست‌دادن را می‌شکند

کانال کنترل روی یک نشست TLS مذاکره می‌کند و سیاست آن با tls-cipher برای TLS 1.2 و tls-ciphersuites برای TLS 1.3 نوشته می‌شود. کانال داده جداگانه با data-ciphers پیکربندی می‌شود، جایی که ناسازگاری اتصالی می‌سازد که برقرار می‌شود و سپس نمی‌تواند ترافیک را عبور دهد. هر دو خطاهایی تولید می‌کنند که از رمز نام می‌برند و به همین دلیل با هم اشتباه گرفته می‌شوند. دست‌دادنی که هرگز کامل نمی‌شود به کانال کنترل اشاره دارد، در حالی که تونل برقرارشده‌ای که بسته‌ها را دور می‌ریزد به کانال داده اشاره دارد.

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

پیش از مقایسه مجموعه‌ها، نسخه‌ها را مقایسه کنید

طرفی که به TLS 1.2 محدود است و طرفی که 1.3 می‌خواهد هیچ نسخه‌ای را مشترک ندارند و هیچ رشته رمزی این شکاف را پر نمی‌کند. یادداشت کنید tls-version-min و tls-version-max را در هر دو طرف، یا پیش‌فرض‌های بیلدهای در حال استفاده را، چون سیاست OpenSSL یک توزیع می‌تواند کف را بالا ببرد بدون آنکه هیچ گزینه OpenVPN این را بگوید. اگر یک طرف یک دستگاه یا کلاینت شخص ثالث باشد، پنجره آن همان چیزی است که فرم‌ور آن اجازه می‌دهد. تنها وقتی پنجره‌ها همپوشانی داشته باشند مقایسه مجموعه‌ها معنایی دارد.

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

فهرست‌های TLS 1.2 و TLS 1.3 با هم نمی‌آمیزند

نام‌های مجموعه TLS 1.2 چیزی شبیه ECDHE-RSA-AES256-GCM-SHA384 هستند و جایشان در tls-cipher است که یک رشته رمز OpenSSL می‌پذیرد. مجموعه‌های TLS 1.3 نامشان مانند TLS_AES_256_GCM_SHA384 است و جایشان در tls-ciphersuites است؛ افزودن یکی به رشته 1.2 فهرست 1.3 را پیکربندی نمی‌کند و تجزیه‌گر ممکن است متن را بپذیرد بدون آنکه هرگز با آن تطبیق دهد. فیلتری که برای یک نسخه درست است درباره دیگری چیزی نمی‌گوید. بنویسید هر فهرست برای کدام نسخه است.

openvpn --show-tls چاپ می‌کند که بیلد محلی از چه چیزهایی پشتیبانی می‌کند، و آن یک سیاهه است نه وعده: ممکن است طرف دور آن مجموعه‌ها را مجاز نداند و پروفایل فعال آن‌ها را فعال نکند. از آن استفاده کنید تا بیلدی را که اصلاً نمی‌تواند مجموعه‌ای ارائه دهد کنار بگذارید و سپس فهرست‌های پیکربندی‌شده را مقایسه کنید.

مذاکره را روی یک اتصال تازه اثبات کنید

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

اگر پیکربندی مشترک تأییدشده‌ای وجود ندارد، پاسخ ارتقا یا برنامه مهاجرت است، نه سیاستی تضعیف‌شده. tls-version-min پایین آوردن، خاموش کردن بررسی یا فعال کردن همه مجموعه‌های قدیمی رد شدن را بدون برآورده کردن نیاز امنیتی‌ای که آن را ساخته بود از میان برمی‌دارد.

نسخه مذاکره‌شده، مجموعه و رمز داده را در بلیت تغییر ثبت کنید. نفر بعدی که با خطای TLS روبه‌رو شود از همان ثبت شروع می‌کند، نه از رشته رمزی که در یک پست انجمن پیدا کرده است.