OCSP در برابر CRL: هر بررسی ابطال در واقع چگونه کار می‌کند

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

گام 1: هر بررسی چه چیزی برمی‌گرداند و چه مدت قابل استفاده می‌ماند

CRL به‌عنوان یک شیء امضاشده منتشر می‌شود که همه گواهی‌هایی را که یک صادرکننده ابطال کرده پوشش می‌دهد، بنابراین بررسی‌کننده آن را یک بار می‌گیرد و تا زمانی که nextUpdate فهرست بگذرد دوباره استفاده می‌کند. پاسخ OCSP باریک‌تر است: دقیقاً برای یک گواهی پاسخ می‌دهد و thisUpdate، producedAt و معمولاً nextUpdate را نیز حمل می‌کند. همین تفاوت همه چیز دیگر را تعیین می‌کند. CRL ذخیره‌شده در حافظه نهان بی‌صدا کهنه می‌شود، چون فایل هنوز تجزیه می‌شود و امضایش هنوز تأیید می‌شود، در حالی که پاسخ OCSP منقضی همان لحظه‌ای که زمان‌های آن را می‌خوانید آشکارا بی‌ارزش است.

پس حافظه نهان نخستین چیزی است که باید مشخص شود: کدام مؤلفه نسخه را نگه می‌دارد و آن نسخه از چه سقفی پیروی می‌کند. در یک دروازه سقف باید nextUpdate منهای یک حاشیه ایمنی باشد، هرگز آنچه یک سرآیند حافظه نهان HTTP تصادفاً پیشنهاد می‌کند. openssl crl -in issuer.crl -noout -lastupdate -nextupdate هر دو تاریخ را چاپ می‌کند، و فهرستی که nextUpdate آن از قبل در گذشته است باید مفقود تلقی شود نه صرفاً کهنه.

گام 2: گواهی مشتری را به کجا هدایت می‌کند

گواهی برگ معمولاً دو نشانه دارد: یک افزونه نقطه توزیع CRL و یک ورودی دسترسی به اطلاعات مرجع برای OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints اولی را چاپ می‌کند و دومی زیر بخش AIA خروجی openssl x509 -in client.pem -noout -text قرار دارد. هر یک از این افزونه‌ها یک اشاره‌گر است نه یک الزام. مشتری‌ای که هرگز بررسی ابطال را پیاده‌سازی نمی‌کند کاملاً خوب به گواهی‌ای متصل می‌شود که افزونه‌هایش پاسخ‌دهی را نام می‌برند که یک سال است مرده.

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

گام 3: پیش از قطعی، fail-closed یا fail-open را انتخاب کنید

پاسخ‌دهی در دسترس‌نیست یا فهرست منقضی، تصمیمی را تحمیل می‌کند: اتصال را رد کنید، یا آن را بپذیرید و شکاف را ثبت کنید. زیرفرمان verify در OpenSSL انتخاب سخت‌گیرانه را صریح می‌کند، چون افزودن -crl_check یک CRL در دسترس‌نیست را به unable to get certificate CRL و یک تأیید ناموفق تبدیل می‌کند. شکست نرم در بیشتر پشته‌ها اصلاً یک پرچم نیست، بلکه نبودِ بررسی است، و دقیقاً به همین دلیل است که تصادفی به محصول می‌رسد.

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

گام 4: ثابت کنید بررسی همان‌جا اجرا می‌شود که ترافیک پذیرفته می‌شود

فرایندی را پیدا کنید که اتصال را پایان می‌دهد یا مجاز می‌کند، و سپس از آن خط پیکربندی‌ای را بخواهید که بررسی ابطال را فعال می‌کند. دروازه‌ای که زنجیره را معتبر می‌داند ولی هرگز درباره ابطال نمی‌پرسد، سیاستی متفاوت از آنچه در مستندات شماست اعمال می‌کند، و هیچ تصویری از یک زنجیره گواهی خلاف آن را ثابت نمی‌کند. OpenVPN این گزینه را crl-verify می‌نویسد؛ strongSwan جست‌وجوهای CRL و OCSP را زیر پیکربندی CA نگه می‌دارد، جایی که crl_uris یا ocsp_uris تنظیم می‌شوند. اگر نمی‌توانید به هیچ‌کدام اشاره کنید، فرض کنید بررسی وجود ندارد.

پاسخ OCSP تنها زمانی معتبر است که CA صادرکننده آن را امضا کرده باشد، یا پاسخ‌دهی که استفاده گسترده از کلید OCSPSigning تفویض‌شده توسط آن CA را دارد آن را امضا کرده باشد، بنابراین پاسخ یک سرویس بی‌ربط چیزی را ثابت نمی‌کند. اگر خودتان پاسخ‌دهی را اجرا می‌کنید، آن را به‌عنوان یک وابستگی سخت پایش کنید، چون یک سرویس مرده یک‌جا به قطعی برای هر مشتری fail-closed تبدیل می‌شود.

گام 5: یک گواهی را عمداً ابطال کنید

یک گواهی آزمایشی بردارید، آن را از همان کانالی که محیط عملیاتی استفاده می‌کند ابطال کنید، و مستقیماً از پاسخ‌دهی بپرسید. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text باید Cert Status: revoked را همراه با زمان ابطال گزارش کند، و پاسخ good یعنی ابطال شما به پاسخ‌دهی‌ای که مشتریانتان می‌پرسند نرسیده است. سپس openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem را اجرا کنید تا همان تصمیم را از مسیر فهرست ببینید. رشته دلیل را بخوانید نه کد خروج را، چون رد ابطال و خطای زنجیره هر دو به شکست می‌رسند.

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