یک همتای قدیمی TLS 1.0 را تحمیل می‌کند: دامنه استثنا را محدود کنید، نه میزبان را

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

شکست را پیش از ویرایش یک دستور به دو بخش تقسیم کنید

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

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

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

شنونده دوم جای صادقانه برای کف ضعیف‌تر است

وقتی دستگاه با کانال داده پیش از 2.5 روی TLS 1.0 متوقف می‌شود، سرور باید کف پایین‌تری برای کانال کنترل و رمز داده‌ای ارائه دهد که کلاینت قدیمی آن را می‌شناسد. دستور جایگزین دقیقاً برای همین همتا وجود دارد، در حالی که فهرست رمزها کلاینت‌های مدرن را روی مجموعه‌های مدرن نگه می‌دارد. هر دو دستور متعلق به شنونده‌اند نه به کاربر یا اتصال، و هیچ گزینه‌ای برای هر کلاینت بعداً آن‌ها را تنگ نمی‌کند. به همین دلیل یک دستگاه قدیمی روی درگاه اصلی تصمیمی درباره هر همتایی است که آن را شریک می‌شود.

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

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

یک گواهی قدیمی ارائه‌دهنده واقعاً چه چیزی را می‌شکند

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

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

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

مقادیر مذاکره‌شده را بخوانید، نه بنر را

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

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

هر استثنا به یک مالک و یک تاریخ نیاز دارد

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

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