شرکت موزیلا درباره شروع آزمایش مکانیزم جدیدی برای تشخیص گواهیهای باطلشده در نسخههای شبانه فایرفاکس — CRLite امکان بررسی کارآمد ابطال گواهی را در پایگاه دادهای که روی سیستم کاربر میزبانی میشود، فراهم میکند. پیادهسازی CRLite در موزیلا در حال توسعه است. تحت مجوز رایگان MPL 2.0. کد مربوط به تولید پایگاه داده و اجزای سرور به زبان ... نوشته شده است. و Go. کامپوننتهای سمت کلاینت برای خواندن دادهها از پایگاه داده به فایرفاکس اضافه شدند. به زبان روست.
تأیید گواهیها، که هنوز هم مورد استفاده قرار میگیرد، شامل سرویسهای خارجی مبتنی بر پروتکل است. (پروتکل وضعیت گواهی آنلاین) نیاز به دسترسی تضمینشده به شبکه دارد، تأخیر قابل توجهی در پردازش درخواست ایجاد میکند (بهطور متوسط ۳۵۰ میلیثانیه) و دارای مشکلات حریم خصوصی است (سرورهای OCSP پاسخدهنده اطلاعاتی در مورد گواهیهای خاص دریافت میکنند که میتوان از آنها برای تعیین وبسایتهایی که کاربر بازدید میکند استفاده کرد). بررسیهای محلی در برابر لیستها نیز موجود است. (لیست ابطال گواهینامه)، اما نکته منفی این روش، حجم بسیار بالای دادههای دانلود شده است - در حال حاضر پایگاه داده گواهینامههای ابطال شده حدود ۳۰۰ مگابایت را اشغال میکند و همچنان در حال افزایش است.
فایرفاکس از سال ۲۰۱۵ از یک لیست سیاه متمرکز برای مسدود کردن گواهیهایی که توسط مراجع صدور گواهی به خطر افتاده یا لغو شدهاند، استفاده کرده است. همراه با درخواست به سرویس برای شناسایی فعالیتهای مخرب احتمالی. OneCRL، مانند در کروم، این سرویس به عنوان واسطهای عمل میکند که CRLها را از CAها جمعآوری میکند و یک سرویس OCSP واحد و متمرکز برای بررسی گواهیهای لغو شده ارائه میدهد و نیاز به ارسال مستقیم درخواستها به CAها را از بین میبرد. با وجود کار گسترده برای بهبود قابلیت اطمینان سرویس تأیید گواهی آنلاین، دادههای تلهمتری نشان میدهد که بیش از ۷٪ از درخواستهای OCSP با مشکل time out مواجه میشوند (چند سال پیش، این رقم ۱۵٪ بود).
به طور پیشفرض، اگر تأیید OCSP امکانپذیر نباشد، مرورگر گواهی را معتبر میداند. این سرویس ممکن است به دلیل مشکلات شبکه و محدودیتهای شبکه داخلی در دسترس نباشد، یا ممکن است توسط مهاجمان مسدود شده باشد. برای دور زدن تأیید OCSP در طول حملهی مرد میانی، صرفاً مسدود کردن دسترسی به سرویس تأیید کافی است. تکنیکی برای جلوگیری نسبی از چنین حملاتی پیادهسازی شده است. که اجازه میدهد خطای درخواست OCSP یا عدم دسترسی به OCSP به عنوان مشکلی در گواهی تفسیر شود، اما این ویژگی اختیاری است و نیاز به طراحی گواهی ویژه دارد.
CRLite به شما امکان میدهد اطلاعات کامل مربوط به تمام گواهیهای باطلشده را در یک ساختار بهراحتی بهروزرسانیشده، تنها با حجم ۱ مگابایت، تجمیع کنید و به شما امکان میدهد کل پایگاه داده CRL را در سمت کلاینت ذخیره کنید.
مرورگر قادر خواهد بود روزانه کپی دادههای مربوط به گواهیهای باطلشده را همگامسازی کند و این پایگاه داده تحت هر شرایطی در دسترس خواهد بود.
CRLite اطلاعات را از ... ترکیب میکند. ، یک گزارش عمومی از تمام گواهینامههای صادر شده و لغو شده، و نتایج اسکن گواهینامهها در اینترنت (لیستهای مختلف CRL از مراجع صدور گواهینامه جمعآوری شده و اطلاعات مربوط به تمام گواهینامههای شناخته شده تجمیع شده است). دادهها با استفاده از آبشاری بستهبندی میشوند. ، یک ساختار احتمالی که امکان تشخیص مثبت کاذب یک عنصر مفقود را فراهم میکند، اما حذف یک عنصر موجود را مستثنی میکند (یعنی، با یک احتمال خاص، تشخیص مثبت کاذب برای یک گواهی معتبر امکانپذیر است، اما تضمین میشود که گواهیهای باطل شده شناسایی شوند).
برای حذف موارد مثبت کاذب، CRLite لایههای اصلاح فیلتر اضافی را معرفی کرده است. پس از تولید ساختار، تمام رکوردهای منبع تکرار میشوند و هرگونه مورد مثبت کاذب شناسایی میشود. بر اساس نتایج این بررسی، یک ساختار اضافی ایجاد میشود که به صورت آبشاری روی اولین مورد قرار میگیرد و هرگونه مورد مثبت کاذب رخ داده را اصلاح میکند. این عملیات تا زمانی که موارد مثبت کاذب در طول بررسی کنترل به طور کامل حذف شوند، تکرار میشود. معمولاً ایجاد ۷ تا ۱۰ لایه برای پوشش کامل تمام دادهها کافی است. از آنجایی که وضعیت پایگاه داده به دلیل همگامسازی دورهای کمی از وضعیت فعلی CRL عقب میماند، تأیید گواهیهای جدید صادر شده از آخرین بهروزرسانی پایگاه داده CRLite با استفاده از پروتکل OCSP، از جمله استفاده از تکنیک انجام میشود. (یک پاسخ OCSP که توسط یک مرجع صدور گواهینامه تأیید شده است، هنگام مذاکره برای اتصال TLS توسط سروری که به سایت سرویس میدهد، ارسال میشود).
با استفاده از فیلترهای بلوم، تصویر لحظهای ماه دسامبر از دادههای WebPKI، که شامل ۱۰۰ میلیون گواهی فعال و ۷۵۰،۰۰۰ گواهی لغو شده است، در یک ساختار ۱.۳ مگابایتی فشرده شد. فرآیند تولید ساختار بسیار پرمصرف است، اما روی یک سرور موزیلا اجرا میشود و کاربر یک بهروزرسانی آماده دریافت میکند. به عنوان مثال، دادههای دودویی مورد استفاده برای تولید، هنگام ذخیره در Redis DBMS تقریباً به ۱۶ گیگابایت حافظه نیاز دارند، در حالی که نسخهبرداری هگزادسیمال از تمام شماره سریالهای گواهی تقریباً ۶.۷ گیگابایت طول میکشد. فرآیند جمعآوری تمام گواهیهای لغو شده و فعال تقریباً ۴۰ دقیقه طول میکشد و تولید ساختار فشرده شده با استفاده از فیلتر بلوم به ۲۰ دقیقه دیگر نیاز دارد.
موزیلا در حال حاضر پایگاه داده CRLite را چهار بار در روز بهروزرسانی میکند (همه بهروزرسانیها به کلاینتها تحویل داده نمیشوند). تولید بهروزرسانی دلتا هنوز پیادهسازی نشده است - bsdiff4 که برای ایجاد بهروزرسانیهای انتشار دلتا استفاده میشود، عملکرد لازم را برای CRLite فراهم نمیکند و منجر به بهروزرسانیهای غیرضروری و حجیم میشود. برای رفع این نقص، برنامههایی برای اصلاح قالب ساختار ذخیرهسازی در حال انجام است تا بازسازی غیرضروری و حذف لایهها از بین برود.
CRLite در حال حاضر در حالت غیرفعال در فایرفاکس عمل میکند و به موازات OCSP برای جمعآوری آمار در مورد عملکرد صحیح آن استفاده میشود. CRLite را میتوان با تنظیم پارامتر security.pki.crlite_mode به ۲ در about:config به حالت تأیید اولیه تغییر داد.
منبع: opennet.ru
