کلاینت ابطالشده هنوز وصل میشود: فهرست هرگز نرسید
ابطال یک ورودی برای بررسی گواهی است، نه فرمانی که نشست را پایان میدهد. مقایسه کنید که یک اتصال تازه و یک تونل در حال اجرا فهرست را چگونه میبینند.
ابطال هرگز به داخل تونل در حال اجرا نمیخزد تا نشستی را پاک کند. فهرست یک ورودی برای بررسی گواهی است و در جریان تبادل کانال کنترلی که نشست TLS را آغاز میکند خوانده میشود. همین یک واقعیت هر دو شگفتی را توضیح میدهد: کلاینت ابطالشده دوباره وصل میشود، چون فهرست هرگز به بررسیکننده نرسید، و نشست موجود زنده میماند، چون هیچکس دوباره چیزی را بررسی نکرد.
فهرست یک ورودی است، نه یک اقدام
در زمان برپایی نشست، سرور گواهی کلاینت را در برابر لنگرهای اعتماد خود اعتبارسنجی میکند و دستور ابطال یک جستوجوی فهرست به این تصمیم میافزاید. بررسی در سرور رخ میدهد، پس کلاینت نمیتواند ببیند که گواهیاش ابطال شده و همان گواهی را ادامه میدهد. بنابراین پروفایلی که هنوز وصل میشود فقط ثابت میکند که بررسیکنندهای زنجیره را پذیرفته، نه اینکه ابطال شکست خورده است.
خود فهرست شیئی امضاشده با تاریخ صدور و تاریخ بهروزرسانی بعدی است. فهرست نامرتبط، فهرستی که مرجع دیگری امضا کرده یا فهرستی که تاریخ بهروزرسانی بعدیاش گذشته، جایگزین فهرست کنونی نیست، و اینکه فهرست کهنه رد شود یا بیصدا پذیرفته شود به نحوه استقرار بستگی دارد.
اتصال تازه در برابر نشست در حال اجرا
ابطال هنگام برقراری یا بازمذاکره نشست ارزیابی میشود، نه در برابر کانال داده برای هر بسته. کلاینتی که از قبل وصل است کلیدهای ترافیک را دارد، پس پس از ظاهر شدن گواهیاش در فهرست هم بستهها را عبور میدهد. فاصله پیشفرض بازمذاکره با ساعت سنجیده میشود، به همین دلیل فهرست بهروزشده میتواند برای تازهواردها اعمال شود در حالی که تونل در حال اجرا برپا میماند.
| Situation | What the list does | When it applies |
|---|---|---|
| Fresh connection | Blocks the handshake | At verification, immediately |
| Renegotiation | Blocks the new exchange | At the next renegotiation interval |
| Established data channel | Nothing | Until the session ends |
اجرای فوری به اقدامی آگاهانه نیاز دارد، نه فقط فهرست. راهاندازی دوباره سرویس هر کلاینت را به اتصال دوباره وادار میکند، در حالی که پایان دادن به یک نشست از طریق رابط مدیریت بقیه را دستنخورده میگذارد. برای هر رخداد یکی را انتخاب کنید و یادداشت کنید کدام را به کار بردید. دو گزینه دامنه اثر متفاوتی دارند و تصمیم واقعی همین است.
همان فایلی را برسانید که بررسیکننده واقعاً میخواند
فهرست باید از سابقه مرجع تولید شود و سپس به هر دستگاهی که گواهیها را بررسی میکند کپی شود. تولید آن روی میزبان CA و هرگز نصب نکردنش روی سرور رایجترین خرابی است و دقیقاً شبیه یک قابلیت ابطال خراب به نظر میرسد.
ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pem
دو جزئیات تعیین میکند که فایل واقعاً خوانده شود. مسیر نسبی نسبت به پوشه پیکربندی حل میشود، پس نسخهای که در پوشه خانگی یک اپراتور جا مانده ممکن است هرگز پیدا نشود. و دیمن معمولاً پس از راهاندازی از امتیازها دست میکشد، پس حساب زمان اجرا به مجوز جستوجو در هر پوشه والد و مجوز خواندن فایل نیاز دارد. هر دو را با حساب زمان اجرا بررسی کنید نه با root، وگرنه آزمون چیز اشتباهی را ثابت میکند.
روی میزبانهای systemd، یک واحد سختشده هم میتواند مسیر را پنهان کند، با نمای فقطخواندنی یا پوشه سیستمی محافظتشده. از داخل سرویس این وضعیت از فایل ناموجود قابل تشخیص نیست، پس پیش از رفتن سراغ خطای مجوز، محدودیتهای واحد را بررسی کنید. پیش از سرزنش حالت فایل، فایل واحد را بخوانید.
روی سرور تأیید کنید، نه روی کلاینت
گزارش سرور نام میبرد که چه رخ داد: باز کردن فهرست، بارگذاری آن یا شکست بررسی با شماره سریال ابطالشده. کلاینت فقط یک شکست عمومی دستدادن را گزارش میکند، به همین دلیل گزارشهای کلاینت جای بدی برای جستوجوی تصمیم ابطال است.
با یک تلاش تازه از پروفایل ابطالشده بررسی کنید و سپس متوقف شوید. اتصال موفق از آن پروفایل نشانه بازبینی مسیر فایل و حساب زمان اجراست، نه فرض اینکه فهرست اشتباه بوده. همان تلاش موفق را به عنوان آزمون پذیرش نگه دارید و اتصال دوبارهای را که خود ندیدهاید نشمارید.
چه چیزی هیچ چیز را ابطال نمیکند
پاک کردن پروفایل از یک لپتاپ، برداشتن فایل گواهی از کلاینت یا گفتن به کاربر که اتصال را متوقف کند چیزی را روی سرور تغییر نمیدهد. گواهی معتبر میماند تا زمانی که مرجع ابطال را ثبت کند و بررسیکننده فهرست حاصل را بخواند.
به همین دلیل ارزش دارد زنجیره را بنویسید: ابطال را ثبت کنید، فهرست را تولید و امضا کنید، دقیقاً همان فایل را توزیع کنید و تأیید کنید که حساب سرویس میتواند آن را بخواند. هر حلقه کوتاه است و هر حلقه گمشده کلاینت ابطالشده را با خوشحالی در حال اتصال میگذارد. یک چکلیست چهارخطی از یک فرض بدون هیچ خط بهتر است.