موزیلا CRLite را برای بررسی گواهی های مشکل ساز TLS پیاده سازی می کند

شرکت موزیلا اعلام کرد درباره شروع آزمایش در بیلدهای شبانه فایرفاکس مکانیزم جدیدی برای شناسایی گواهینامه های باطل شده - CRLite. CRLite به شما امکان می دهد تا بررسی موثر ابطال گواهی را در برابر پایگاه داده میزبانی شده در سیستم کاربر سازماندهی کنید. پیاده سازی CRLite موزیلا منتشر شده تحت مجوز رایگان MPL 2.0. کد تولید پایگاه داده و اجزای سرور در آن نوشته شده است پــایتــون و برو. قطعات کلاینت برای خواندن داده ها از پایگاه داده به فایرفاکس اضافه شده است آماده شده به زبان رست

تأیید گواهی با استفاده از سرویس های خارجی بر اساس پروتکلی که هنوز استفاده می شود OCSP (پروتکل وضعیت گواهی آنلاین) به دسترسی تضمین شده به شبکه نیاز دارد، منجر به تاخیر قابل توجهی در پردازش درخواست می شود (به طور متوسط ​​350 میلی ثانیه) و با اطمینان از محرمانه بودن مشکل دارد (سرورهای OCSP که به درخواست ها پاسخ می دهند اطلاعات مربوط به گواهی های خاص را دریافت می کنند، که می تواند برای قضاوت در مورد آنچه سایت هایی که کاربر باز می کند). همچنین امکان بررسی محلی در برابر لیست ها وجود دارد C.R.L. (Certificate Revocation List)، اما عیب این روش حجم بسیار زیاد داده های دانلود شده است - در حال حاضر پایگاه داده گواهی های باطل شده حدود 300 مگابایت را اشغال کرده و رشد آن ادامه دارد.

فایرفاکس از سال 2015 برای مسدود کردن گواهینامه هایی که توسط مقامات صدور گواهینامه به خطر افتاده و باطل شده اند، از یک لیست سیاه متمرکز استفاده کرده است. OneCRL در ترکیب با تماس با سرویس مرور ایمن Google برای شناسایی فعالیت های مخرب احتمالی OneCRL، مانند مجموعه های CRLS در Chrome، به عنوان یک پیوند میانی عمل می‌کند که فهرست‌های CRL را از مقامات صدور گواهی جمع‌آوری می‌کند و یک سرویس OCSP متمرکز واحد را برای بررسی گواهی‌های باطل شده ارائه می‌کند و امکان ارسال مستقیم درخواست‌ها به مقامات صدور گواهی‌نامه را ممکن می‌سازد. علیرغم تلاش زیاد برای بهبود قابلیت اطمینان سرویس تأیید گواهی آنلاین، داده های تله متری نشان می دهد که بیش از 7 درصد درخواست های OCSP به پایان می رسد (چند سال پیش این رقم 15 درصد بود).

به طور پیش فرض، اگر تأیید از طریق OCSP غیرممکن باشد، مرورگر گواهی را معتبر می داند. این سرویس ممکن است به دلیل مشکلات و محدودیت های شبکه در شبکه های داخلی در دسترس نباشد یا توسط مهاجمان مسدود شود - برای دور زدن بررسی OCSP در طول حمله MITM، به سادگی دسترسی به سرویس چک را مسدود کنید. تا حدی برای جلوگیری از چنین حملاتی، تکنیکی به کار گرفته شده است باید منگنه، که به شما امکان می دهد خطای دسترسی OCSP یا در دسترس نبودن OCSP را به عنوان مشکل گواهی تلقی کنید، اما این ویژگی اختیاری است و نیاز به ثبت ویژه گواهی دارد.

CRLite به شما امکان می دهد اطلاعات کامل مربوط به تمام گواهی های باطل شده را در یک ساختار به راحتی به روز شده، تنها 1 مگابایت ادغام کنید، که امکان ذخیره یک پایگاه داده کامل CRL را در سمت مشتری فراهم می کند.
مرورگر می‌تواند کپی خود را از داده‌های مربوط به گواهی‌های باطل شده روزانه همگام‌سازی کند و این پایگاه داده تحت هر شرایطی در دسترس خواهد بود.

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

برای حذف موارد مثبت کاذب، CRLite سطوح فیلتر اصلاحی اضافی را معرفی کرده است. پس از ایجاد ساختار، تمام سوابق منبع جستجو شده و هر گونه مثبت کاذب شناسایی می شود. بر اساس نتایج این بررسی، یک ساختار اضافی ایجاد می‌شود که بر روی اولی آبشاری می‌شود و مثبت‌های کاذب حاصل را تصحیح می‌کند. این عملیات تا زمانی تکرار می شود که مثبت کاذب در حین بررسی کنترل کاملاً از بین برود. به طور معمول، ایجاد 7-10 لایه برای پوشش کامل تمام داده ها کافی است. از آنجایی که وضعیت پایگاه داده، به دلیل همگام سازی دوره ای، کمی از وضعیت فعلی CRL عقب است، بررسی گواهی های جدید صادر شده پس از آخرین به روز رسانی پایگاه داده CRLite با استفاده از پروتکل OCSP، از جمله با استفاده از منگنه OCSP (یک پاسخ OCSP تایید شده توسط یک مرجع صدور گواهینامه توسط سروری که به سایت سرویس می دهد هنگام مذاکره برای اتصال TLS منتقل می شود).

با استفاده از فیلترهای بلوم، برش اطلاعات دسامبر WebPKI، که 100 میلیون گواهی فعال و 750 هزار گواهی لغو شده را پوشش می‌دهد، توانست در ساختاری با حجم 1.3 مگابایت بسته‌بندی شود. فرآیند تولید ساختار کاملاً نیازمند منابع است، اما بر روی سرور موزیلا انجام می شود و به روز رسانی آماده به کاربر داده می شود. به عنوان مثال، در فرم باینری، داده های منبع مورد استفاده در طول تولید به حدود 16 گیگابایت حافظه زمانی که در Redis DBMS ذخیره می شود، نیاز دارند، و در فرم هگزادسیمال، تخلیه تمام شماره های سریال گواهی ها حدود 6.7 گیگابایت طول می کشد. فرآیند جمع‌آوری تمامی گواهی‌های باطل و فعال حدود 40 دقیقه طول می‌کشد و فرآیند تولید یک ساختار بسته‌بندی شده بر اساس فیلتر بلوم 20 دقیقه دیگر طول می‌کشد.

موزیلا در حال حاضر تضمین می کند که پایگاه داده CRLite چهار بار در روز به روز می شود (همه به روز رسانی ها به مشتریان ارائه نمی شوند). تولید به‌روزرسانی‌های دلتا هنوز پیاده‌سازی نشده است - استفاده از bsdiff4 که برای ایجاد به‌روزرسانی‌های دلتا برای نسخه‌ها استفاده می‌شود، کارایی کافی را برای CRLite فراهم نمی‌کند و به‌روزرسانی‌ها به‌طور غیرمنطقی بزرگ هستند. برای از بین بردن این اشکال، برنامه ریزی شده است که قالب ساختار ذخیره سازی مجدداً کار شود تا بازسازی و حذف غیر ضروری لایه ها حذف شود.

CRLite در حال حاضر در فایرفاکس در حالت غیرفعال کار می کند و به موازات OCSP برای جمع آوری آمار در مورد عملکرد صحیح استفاده می شود. CRLite را می توان به حالت اسکن اصلی تغییر داد؛ برای انجام این کار، باید پارامتر security.pki.crlite_mode = 2 را در about:config تنظیم کنید.

منبع: opennet.ru