בספריית ה-ssl של Erlang/OTP התגלתה חולשה בציון 9.3 מתוך 10, והצד שנפגע בה הוא דווקא הלקוח: המערכת שיוזמת את החיבור, לא זו שמקבלת אותו. מי שעונה לחיבור TLS 1.3 יכול לגרום ללקוח להשלים את ההתחברות בלי לבדוק את התעודה של הצד השני, ובלי שהוא מחזיק תעודה, מפתח פרטי או היסטוריה כלשהי מול אותו לקוח.

מה החולשה?

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

בתוך לחיצת היד של TLS 1.3 קיים מסלול קיצור: אם שני הצדדים כבר דיברו קודם, הם יכולים להתבסס על מפתח משותף שנקבע אז במקום להתחיל הכול מחדש. הצד השני מסמן את המסלול הזה באמצעות הרחבה בשם pre_shared_key. הלקוח של Erlang/OTP התייחס עצם הופעתה של ההרחבה הזאת בהודעת ה-ServerHello כהוכחה שמדובר בחידוש שיחה, בלי לבדוק קודם אם הוא עצמו הציע כזה מלכתחילה.

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

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

מי מושפע?

הטווח רחב. הרשומה מציינת את OTP החל מגרסה 22.2 ועד הגרסאות 27.3.4.18, 28.5.0.7 ו-29.1.1, שבהן החולשה נסגרה. מי שעוקב אחרי מספר הגרסה של יישומון ה-ssl עצמו ולא אחרי OTP כולו, הטווח שם הוא מ-9.5 ועד 11.2.12.13, 11.6.0.6 ו-11.7.7.

שתי נקודות מהרשומה חותכות את השאלה מי בפנים ומי בחוץ. הראשונה: תצורת ברירת המחדל של הלקוח חשופה, כלומר לא נדרשה כאן הגדרה חריגה כדי להיכנס לבעיה. השנייה: לקוחות שמוגבלים ל-TLS 1.2 אינם חשופים, מפני שהמסלול שנשבר קיים רק ב-TLS 1.3.

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

האם מנוצלת בפועל?

החולשה אינה רשומה בקטלוג ה-KEV של CISA, סוכנות הסייבר האמריקאית, הרשימה שבה מסומנות חולשות שידוע כי תוקפים משתמשים בהן בשטח. היא גם חדשה יחסית: הרשומה התפרסמה ב-NVD ב-22 בספטמבר 2026. היעדר רישום ב-KEV אומר שהניצול טרם תועד ונאסף לשם, לא שאפשר להניח שהוא לא קורה.

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

מה עושים?

עדכנו את OTP לגרסה שסוגרת את החולשה בענף שאתם מריצים: 27.3.4.18, 28.5.0.7 או 29.1.1. אם אתם מנהלים גרסאות ברמת היישומון, הגרסאות המקבילות של ssl הן 11.2.12.13, 11.6.0.6 ו-11.7.7. אין צורך לעבור ענף מרכזי, התיקון קיים בשלושת הענפים.

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

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

הודעת האבטחה של גוף ה-CNA של Erlang היא המקור לטווחי הגרסאות ולפרטי התיקון.