פרטים טכניים על ההשבתה האחרונה של תוספות בפיירפוקס

הערה מתרגם: לנוחיות הקוראים, תאריכים ניתנים בזמן מוסקבה

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

רקע: תוספות וחתימות

למרות שאנשים רבים משתמשים בדפדפן מחוץ לקופסה, פיירפוקס תומך בהרחבות הנקראות "תוספות". בעזרתם, משתמשים מוסיפים תכונות שונות לדפדפן. יש למעלה מ-15 אלף תוספות: מ חסימת מודעות до לנהל מאות כרטיסיות.

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

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

שימו לב שלכל תעודה יש ​​"נושא" (אליו הונפקה התעודה) ו"מנפיק" (שהנפיק את התעודה). במקרה של תעודת שורש, "נושא" = "מוציא", אך לגבי תעודות אחרות, מנפיק התעודה הוא נושא תעודת האב שבאמצעותה הוא חתום.

נקודה חשובה: כל תוסף חתום על ידי תעודת סיום ייחודית, אך כמעט תמיד תעודות סיום אלו חתומות על ידי אותה תעודת ביניים.

הערת המחבר: היוצא מן הכלל הוא תוספות ישנות מאוד. באותה תקופה נעשה שימוש בתעודות ביניים שונות.

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

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

צמצום נזקים

ברגע שהבנו מה קרה, ניסינו למנוע מהמצב להחמיר.

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

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

פעולה מקבילה

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

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

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

די מהר הגענו לשתי אסטרטגיות עיקריות, בהן השתמשנו במקביל:

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

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

החלפת תעודה

כפי שציינתי למעלה, זה היה נדרש:

• ליצור תעודה חוקית חדשה
• להתקין אותו מרחוק בפיירפוקס

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

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

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

הערת המחבר: קוראים המכירים את WebPKI ישימו לב שתעודות צולבות פועלות בדיוק באותו אופן.

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

נורמנדי ומערכת המחקר

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

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

אז הפתרון הוא ליצור מחקר:

• התקנת האישור החדש שיצרנו למשתמשים
• לאלץ את הדפדפן לבדוק מחדש תוספים מושבתים כדי שיפעלו שוב

"אבל רגע," אתה אומר, "תוספות לא עובדות, איך אני יכול להפעיל תוסף מערכת?" בואו לחתום על זה עם תעודה חדשה!

מחברים את הכל... למה זה לוקח כל כך הרבה זמן?

אז, התוכנית: הנפק אישור חדש שיחליף את הישן, צור תוסף מערכת והתקן אותו למשתמשים דרך נורמנדי. הבעיות, כאמור, החלו ב-4 במאי בשעה 4:00, וכבר ב-12:44 באותו היום, פחות מ-9 שעות לאחר מכן, שלחנו תיקון לנורמנדי. לקח עוד 6-12 שעות עד שהוא הגיע לכל המשתמשים. לא רע בכלל, אבל אנשים בטוויטר שואלים למה לא יכולנו לפעול מהר יותר.

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

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

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

שלבים אחרונים

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

• משתמשים שהשביתו מחקר או טלמטריה
• משתמשים בגרסת האנדרואיד (Fennec), שבה מחקר אינו נתמך כלל
• משתמשים ב-Builds מותאמים אישית של Firefox ESR בארגונים שבהם לא ניתן להפעיל טלמטריה
• משתמשים שיושבים מאחורי פרוקסי MitM, מכיוון שמערכת התקנת התוספים שלנו משתמשת בהצמדת מפתח, מה שלא עובד עם פרוקסי כאלה
• משתמשים בגרסאות מדור קודם של Firefox שאינן תומכות במחקר

אנחנו לא יכולים לעשות שום דבר לגבי הקטגוריה האחרונה של משתמשים - הם עדיין צריכים לעדכן לגרסה החדשה של פיירפוקס, מכיוון שלמיושנים יש פגיעויות רציניות שטרם בוצעו. אנו יודעים שחלק מהאנשים נשארים בגירסאות ישנות יותר של פיירפוקס מכיוון שהם רוצים להפעיל הרחבות ישנות, אבל רבים מההרחבות הישנות כבר הועברו לגרסאות חדשות יותר של הדפדפן. עבור משתמשים אחרים, פיתחנו תיקון שיתקין תעודה חדשה. זה שוחרר כגרסה של תיקון באגים (הערת המתרגם: Firefox 66.0.5), כך שאנשים יקבלו את זה - סביר להניח שכבר קיבלו את זה - דרך ערוץ העדכונים הרגיל. אם אתה משתמש במבנה מותאם אישית של Firefox ESR, אנא צור קשר עם המתחזק שלך.

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

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

השיעורים

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

ברור שכל זה לא היה צריך לקרות בכלל. ברור שכדאי להתאים את התהליכים שלנו כדי להפחית את הסבירות לאירועים כאלה ולהקל על התיקון.

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

שנית, אנו זקוקים למנגנון שיספק עדכונים במהירות למשתמשים, גם כאשר - במיוחד כאשר - כל השאר נכשל. זה היה נהדר שהצלחנו להשתמש במערכת "מחקר", אבל זה כלי לא מושלם ויש לו כמה תופעות לוואי לא רצויות. בפרט, אנו יודעים שלמשתמשים רבים יש עדכונים אוטומטיים מופעלים, אך מעדיפים לא להשתתף במחקר (אני מודה, גם אני כיבית אותם!). יחד עם זאת, אנו זקוקים לדרך לשלוח עדכונים למשתמשים, אך לא משנה מה היישום הטכני הפנימי, המשתמשים צריכים להיות מסוגלים להירשם לעדכונים (כולל תיקונים חמים) אך לבטל את הסכמתם לכל השאר. בנוסף, ערוץ העדכון צריך להיות רספונסיבי יותר ממה שהוא כרגע. אפילו ב-6 במאי, עדיין היו משתמשים שלא ניצלו את התיקון או את הגרסה החדשה. על הבעיה הזו כבר עבדו, אבל מה שקרה הראה כמה היא חשובה.

לבסוף, נסקור מקרוב את ארכיטקטורת האבטחה של התוסף כדי לוודא שהיא מספקת את רמת האבטחה הנכונה עם סיכון מינימלי לשבור משהו.

בשבוע הבא נבחן את התוצאות של ניתוח מעמיק יותר של מה שקרה, אבל בינתיים אשמח לענות על שאלות במייל: [מוגן בדוא"ל]

מקור: linux.org.ru