מוזילה מיישמת CRLite כדי לבדוק אם יש אישורי TLS בעייתיים

חברת מוזילה הוכרז על התחלת הבדיקה בבנייה לילית של Firefox מנגנון חדש לאיתור אישורים שבוטלו - CRLite. CRLite מאפשר לך לארגן בדיקת ביטול אישור יעיל מול מסד נתונים המתארח במערכת של המשתמש. יישום CRLite של מוזילה יצא לאור תחת רישיון MPL 2.0 החינמי. הקוד להפקת רכיבי מסד הנתונים והשרת נכתב פיתון ו ... צא. חלקי לקוח נוספו ל-Firefox לקריאת נתונים ממסד הנתונים מוּכָן בשפת חלודה.

אימות תעודה באמצעות שירותים חיצוניים המבוססים על הפרוטוקול שעדיין נמצא בשימוש OCSP (Online Certificate Status Protocol) דורש גישה מובטחת לרשת, מוביל לעיכוב משמעותי בעיבוד הבקשות (350ms בממוצע) ויש לו בעיות עם הבטחת סודיות (שרתי OCSP המגיבים לבקשות מקבלים מידע על אישורים ספציפיים, שניתן להשתמש בהם כדי לשפוט האם מה אתרים שהמשתמש פותח). קיימת גם אפשרות לבדיקה מקומית מול רשימות C.R.L. (רשימת ביטולי אישורים), אך החיסרון בשיטה זו הוא הגודל הגדול מאוד של הנתונים שהורדו - נכון להיום מאגר התעודות שנשללו תופס כ-300 מגה-בייט והצמיחה שלו נמשכת.

כדי לחסום אישורים שנפרצו ונשללו על ידי רשויות האישורים, Firefox השתמש ברשימה שחורה מרכזית מאז 2015 OneCRL בשילוב עם קריאה לשירות גלישה בטוחה של Google כדי לזהות פעילות זדונית אפשרית. OneCRL, כאילו CRL סטים ב-Chrome, פועל כקישור ביניים שאוסף רשימות CRL מרשויות אישורים ומספק שירות OCSP מרכזי יחיד לבדיקת אישורים שבוטלו, מה שמאפשר לא לשלוח בקשות ישירות לרשויות האישור. למרות עבודה רבה לשיפור האמינות של שירות אימות האישורים המקוון, נתוני טלמטריה מראים שיותר מ-7% מבקשות OCSP פסק זמן (לפני כמה שנים נתון זה היה 15%).

כברירת מחדל, אם אי אפשר לאמת באמצעות OCSP, הדפדפן מחשיב את האישור כתקף. השירות עשוי להיות לא זמין עקב בעיות רשת והגבלות ברשתות פנימיות, או חסום על ידי תוקפים - כדי לעקוף את בדיקת ה-OCSP במהלך מתקפת MITM, פשוט חסום את הגישה לשירות הסימון. חלקית כדי למנוע התקפות כאלה, יושמה טכניקה מהדק חובה, המאפשר לך להתייחס לשגיאת גישה של OCSP או חוסר זמינות של OCSP כבעיה באישור, אך תכונה זו היא אופציונלית ודורשת רישום מיוחד של האישור.

CRLite מאפשר לך לאחד מידע מלא על כל האישורים שבוטלו למבנה המתעדכן בקלות, בגודל 1 MB בלבד, המאפשר לאחסן מסד נתונים CRL שלם בצד הלקוח.
הדפדפן יוכל לסנכרן את העותק שלו של הנתונים על אישורים שנשללו מדי יום, ומאגר מידע זה יהיה זמין בכל תנאי.

CRLite משלב מידע מ שקיפות תעודה, יומן ציבורי של כל התעודות שהונפקו והבוטלו, ותוצאות סריקת התעודות באינטרנט (נאספות רשימות CRL שונות של רשויות האישור ומצטבר מידע על כל התעודות המוכרות). הנתונים נארזים באמצעות מדורגים מסנני פריחה, מבנה הסתברותי המאפשר זיהוי שגוי של אלמנט חסר, אך אינו כולל השמטה של ​​אלמנט קיים (כלומר, בהסתברות מסוימת, תיתכן חיוב שגוי לתעודה נכונה, אך מובטח זיהוי של אישורים שנשללו).

כדי לבטל תוצאות חיוביות שגויות, CRLite הציגה רמות סינון מתקנות נוספות. לאחר יצירת המבנה, כל רשומות המקור מתבצעות ומזהות כל תוצאות חיוביות כוזבות. בהתבסס על תוצאות בדיקה זו, נוצר מבנה נוסף, אשר נשפך אל המבנה הראשון ומתקן את התוצאות השגויות המתקבלות. הפעולה חוזרת על עצמה עד לביטול מוחלט של תוצאות חיוביות כוזבות במהלך בדיקת הבקרה. בדרך כלל, יצירת 7-10 שכבות מספיקה כדי לכסות לחלוטין את כל הנתונים. מאחר שמצב מסד הנתונים, עקב סנכרון תקופתי, מפגר מעט מהמצב הנוכחי של ה-CRL, בדיקת תעודות חדשות שהונפקו לאחר העדכון האחרון של מסד הנתונים של CRLite מתבצעת באמצעות פרוטוקול OCSP, כולל שימוש ב- סיכות OCSP (תגובת OCSP מאושרת על ידי רשות אישורים מועברת על ידי השרת המשרת את האתר בעת משא ומתן על חיבור TLS).

באמצעות מסנני Bloom, ניתן לארוז את נתח המידע של דצמבר מ-WebPKI, המכסה 100 מיליון אישורים פעילות ו-750 אלף אישורים שבוטלו, במבנה של 1.3 מגה-בייט בגודל. תהליך יצירת המבנה הוא די עתיר משאבים, אך הוא מבוצע בשרת מוזילה והמשתמש מקבל עדכון מוכן. לדוגמה, בצורה בינארית, נתוני המקור המשמשים במהלך היצירה דורשים כ-16 GB של זיכרון כאשר הם מאוחסנים ב-Redis DBMS, ובצורה הקסדצימלית, dump של כל המספרים הסידוריים של האישורים לוקח בערך 6.7 GB. תהליך איסוף כל האישורים שבוטלו והפעילים אורך כ-40 דקות, ותהליך יצירת מבנה ארוז המבוסס על מסנן Bloom אורך כ-20 דקות נוספות.

מוזילה דואגת כרגע שמסד הנתונים של CRLite מתעדכן ארבע פעמים ביום (לא כל העדכונים מועברים ללקוחות). יצירת עדכוני דלתא עדיין לא יושמה - השימוש ב-bsdiff4, המשמש ליצירת עדכוני דלתא עבור מהדורות, אינו מספק יעילות נאותה עבור CRLite והעדכונים גדולים באופן בלתי סביר. כדי לבטל את החיסרון הזה, מתוכנן לעבד מחדש את הפורמט של מבנה האחסון כדי למנוע בנייה מחדש ומחיקת שכבות מיותרות.

CRLite פועל כיום בפיירפוקס במצב פסיבי ומשמש במקביל ל-OCSP לצבירת סטטיסטיקות לגבי הפעולה הנכונה. ניתן להעביר את CRLite למצב סריקה ראשי; לשם כך, עליך להגדיר את הפרמטר security.pki.crlite_mode = 2 ב- about:config.

מקור: OpenNet.ru