SECLEVEL=0 نشانه را درمان می‌کند، نه گواهی را

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

مشخص کنید کدام کتابخانه و کدام سیاست در کار است

SECLEVEL مفهومی از OpenSSL است، پس نخستین پرسش این است که آیا ساخت شما اصلاً از OpenSSL استفاده می‌کند. OpenVPN می‌تواند به بیش از یک کتابخانهٔ رمزنگاری پیوند بخورد و تنظیمی که برای یکی از آن‌ها اعمال می‌شود برای بقیه بی‌معناست. از فایل دودویی بپرسید با چه چیزی ساخته شده، سپس از کتابخانه بپرسید کدام نسخه و پیکربندی را بارگذاری کرده است:

openvpn --version | head -3
openssl version -a

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

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

سه چیزی را که می‌توانند رد شوند جدا کنید

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

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

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

ورودی را تغییر دهید، نه آستانه را

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

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

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

اگر باید پایینش بیاورید، محدودش کنید و ثبتش کنید

گاهی یک استثنای سازگاری تأییدشده پاسخ درست است، به‌ویژه برای همتای قدیمی با برنامهٔ بازنشستگی تاریخ‌دار. آن را به خدمتی که نیاز دارد محدود کنید نه به کل میزبان: یک فایل پیکربندی مخصوص خدمت یا یک پیکربندی اختصاصی OpenSSL شعاع تأثیر کمتری از یک خروجی در نمایهٔ سراسری دارد.

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

بازگشت باید یک گام باشد که پیش‌تر آزموده‌اید. پیکربندی قبلی را نگه دارید، تغییر را اعمال کنید، تأیید کنید که سرویس شروع می‌شود و دقیقاً بدانید در صورت رفتار متفاوت اتصال بعدی کدام فایل را بازگردانید.

پس از آن هویت و حفاظت را بررسی کنید

اتصال موفق تنها ثابت می‌کند که شرایط بازبینی‌شده آن را پذیرفته‌اند. تأیید کنید که بررسی نام میزبان و همتا هنوز کار خود را می‌کند، گواهی در استفاده همانی است که قصد استقرارش را داشتید و کانال دادهٔ مذاکره‌شده با سیاستی که فکر می‌کنید دارید مطابقت دارد.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

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

تحویلی که از حسابرسی جان سالم به در می‌برد می‌گوید کدام سیاست کدام ورودی را رد کرد، چه چیزی تغییر یافت و در نتیجه چه چیزی همچنان پذیرفته می‌شود. «با SECLEVEL=0 کار می‌کند» مشاهده‌ای دربارهٔ یک اتصال است، نه ارزیابی امنیتی استقرار.