• בלוג
  • מה גרם להודעת השגיאה המוזרה sec_error_ocsp_unknown_cert

מה גרם להודעת השגיאה המוזרה sec_error_ocsp_unknown_cert

למשך כמה שעות בשבוע שעבר גולשים שהשתמשו בפיירפוקס קיבלו את הודעת השגיאה בכותרת כשניסו להתחבר. כשחקרתי את התופעה גיליתי כמה דברים שהפתיעו אותי על תעודות HTTPS. 

1. מהו אותו OCSP Server

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

ההפתעה הראשונה היתה כמובן השם OCSP, מאחר ולא זכרתי שהשתמשתי בטכנולוגיה בשם זה בעת בניית האתר. חיפוש קצר בגוגל שלח אותי לעמוד הויקיפדיה של Online Certificate Status Protocol. כאן כבר התחלתי להבין שהבעייה לא ממש נמצאת בידיים שלי.

כך נראה האתר לגולשי פיירפוקס בשבוע שעבר:

2. למה משמש OCSP

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

הבעייה מתחילה אם מאיזושהי סיבה אני מחליט לבטל את התעודה: למשל אם האקרים פרצו לאתר וגנבו לי את המפתח הפרטי. מפתח פרטי הינו קובץ על השרת המאפשר את השימוש בתעודה, ומי שמחזיק במפתח הפרטי שמתאים לתעודה יכול להתחזות בקלות לבעל התעודה.

במקרה כזה אני אעביר ל Startcom בקשה לביטול התעודה שלי, והם יצטרכו באיזשהו אופן לעדכן את כל הגולשים הפוטנצאליים שלא יתנו יותר אמון בתעודה זו. הודעת הביטול חייבת להתבצע לאחר שאני באופן יזום ביטלתי את התעודה, וחייבת להגיע לכל דפדפן פוטנציאלי. בדוגמת הפריצה שתיארתי קודם, דפדפן שלא יקבל את הודעת הביטול יציג את מנעול ה HTTPS גם באתר מתחזה.

המנגנון המקורי של הודעות ביטול נקרא CRL (או Certificate Revocation List). בכל פעם שדפדפן מגיע לאתר מאובטח עליו ליצור קשר באופן יזום עם ספק התעודה המתאים, במקרה שלי Startcom, ולקחת את ה CRL העדכני. שם הדפדפן יבדוק שהתעודה לא בוטלה ורק לאחר מכן יוכל להציג את תוכן האתר לגולש.
מנגנון OCSP הוא שכלול של CRL שנותן ביצועים טובים יותר באמצעות העברת פחות מידע בבקשה: במקום לקבל את כל רשימת הביטולים, ב OCSP הדפדפן מקבל מידע רק עבור התעודה של אתר ספציפי.

3. עכשיו כבר התחלתי להבין מה קורה

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

נותרה רק שאלה אחת: למה גולשים שהשתמשו בדפדפן כרום לא חוו את אותה התקלה?

4. כרום לא משתמש ב OCSP

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

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

היתרון בגישה הוא שיפור ביצועים בגלישה לאתר, ובנוסף ביטול התלות בשרת OCSP צד שלישי לצורך גישה לאתרים מאובטחים. החסרון הוא שלוקח יותר זמן ממועד ביטול תעודה ועד שדפדפן כרום יזהה שמדובר בתעודה מבוטלת. אפשר לקרוא עוד על מנגנון ביטול התעודות בכרום באתר המפתחים כאן:
https://dev.chromium.org/Home/chromium-security/crlsets