הסבר אבטחה · נבדק ב־1 בנובמבר 2026. המאמר עוסק באירוע שפורסם ב־6 באוקטובר, ולא בתקיפה חדשה שהוכרזה היום.
בדיווח של גוגל מ־6 באוקטובר מתוארות חטיפות בסיומות .gh, .sl ו־.as. התוקפים שינו רשומות DNS סמכותיות והשיגו תעודות HTTPS לא מורשות. לפי גוגל, מערכותיה לא נפרצו ולא נמצאה סיבה להאשים את רשויות ההנפקה. Chrome חסם תעודות שזוהו, וגוגל פעלה גם לביטולן אצל המנפיקים. משתמשי Chrome לא נדרשו לפעול, אך לא הובטחו זיהוי מלא או הגנה בלקוחות אחרים.
שלושה מנגנונים עם תפקידים שונים
כדאי להפריד בין שלוש שאלות תפעוליות: מי רשאי לקבל תעודה, כיצד מגלים תעודה בלתי צפויה, וכיצד גורמים ללקוחות להפסיק לתת בה אמון. בדיקה שהאתר נטען בהצלחה אינה נותנת תשובה מלאה לאף אחת מהשאלות האלה.
CRLSets חוסמים תעודות. בתיעוד Chromium הם מתוארים כמנגנון החסימה של Chrome למצבי חירום. הם כוללים גם חלק מביטולי התעודות שנאספים מרשימות הביטול של רשויות ההנפקה. זו אינה רשימה מלאה של כל תעודה שבוטלה בעולם. ההבחנה חשובה כשבודקים אירוע שמשפיע על דפדפנים, יישומים ולקוחות מובנים שונים. תיעוד CRLSets של Chromium מפרט את היקף המנגנון.
Certificate Transparency מאפשר לגלות הנפקות. יומנים ציבוריים שניתן להוסיף אליהם רשומות מאפשרים למנטרים למצוא תעודות ותעודות מקדימות המשויכות לדומיין. רישום ביומן מספק נראות, ולא אישור של בעל הדומיין. לכן רשומה לא מוכרת מחייבת בירור, ולא מסקנה אוטומטית שהתרחשה פריצה. יש להשוות אותה לרישומי ההנפקה ולשירותים המורשים לנהל תעודות. ראו כיצד CT פועל ואת רשימת שירותי הניטור.
CAA מגביל הנפקות עתידיות. רשומת Certification Authority Authorization מגדירה מנפיקים מורשים. היא נבדקת בעת ההנפקה, ולא משמשת את הדפדפן לפסילת תעודה קיימת. לכן שינוי CAA אינו תחליף לביטול תעודה. תעודה שאינה תואמת למדיניות הנוכחית עשויה הייתה להיות מותרת לפי מדיניות קודמת. RFC 8659 מגדיר את הגבולות האלה.
הרשאה למנפיק רחבה יותר מהרשאה לחשבון שלכם
RFC 8657 מוסיף שתי הגבלות שימושיות: accounturi מזהה חשבונות מורשים אצל המנפיק, ואילו validationmethods מגביל את שיטות האימות. לפני שמסתמכים עליהן, יש לוודא שהמנפיק תומך בהן. הגדרה שגויה עלולה לחסום חידוש תקין. האצלת DNS יכולה גם לעקוף הגבלות ברמה שמעליה, ולכן אין כאן הגנה גורפת מפני תוקף השולט ב־DNS הרלוונטי.
לדוגמה, Let’s Encrypt מתעד תמיכה בקישור לחשבון ובשיטות HTTP-01, DNS-01 ו־TLS-ALPN-01. התיעוד גם מבהיר שהרשאות CAA מצטברות: רשומה מתירנית נוספת יכולה לאפשר הנפקה. צריך לבדוק את מכלול הרשומות החלות, לרבות כללי תעודות כוכבית ושירותים שהואצלה להם שליטה, ולא להסתפק בשורה אחת שנראית מרגיעה.
בדיקה מעשית לבעלי דומיינים
זוהי רשימת בדיקות תפעולית, ולא קביעה שדומיין מסוים נפרץ:
- בנו מצאי אחד. רשמו דומיינים פעילים, אזוריים וחונים, מפעילי DNS, שירותי תעודות מאושרים ואת האחראי לכל דומיין.
- מנו אחראי להתראות. מישהו צריך להשוות רשומות CT בלתי צפויות לפעילות תקינה של שירותי CDN, אירוח וחידוש תעודות.
- בררו לפני שינוי מדיניות. תעדו את התעודה, המנפיק, הזמנים ושינויי ה־DNS הרלוונטיים. העבירו הנפקה שלא נמצא לה הסבר לספקים האחראים לבדיקה.
- בדקו את ההתאוששות מקצה לקצה. שחזור DNS, ביטול תעודות וחידוש תקין הם בדיקות נפרדות. בחנו שינויי CAA מגבילים מול תהליך החידוש האמיתי שלכם.
הלקח המעשי הוא לחבר בין ניהול הדומיין, מצאי התעודות והתגובה לאירועים. התערבות של דפדפן יכולה לסייע בצמצום הנזק, אך הארגון עדיין צריך לדעת אילו תעודות התכוון לאשר.
לקריאה נוספת: המדריך שלנו ל־Certificate Transparency.