חורי אבטחה בתעודות HTTPS

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

כשאנו גולשים באתר, אנו תמיד מחפשים את סימן המנעול הקטן בכרום או בפיירפוקס שמראה שהחיבור בינינו לבין האתר מוצפן. כלומר שאיש לא יכול לקרוא או לשנות את התקשורת בינינו לבין האתר. HTTPS עובד עם הצפנה א-סימטרית – כלומר הצפנה המאפשרת החלפת מפתח בין שני גורמים כשיש תווך עויין ביניהם. אחרי ההצפנה הא-סימטרית מוחלף מפתח של הצפנה סימטרית והתקשורת מאובטחת. אנו מוגנים להלכה מהתקפת Man In The Middle – בראשי תבות MITM. התקפה שבמסגרתה תוקף בעצם מתלבש על התקשורת בינינו לבין השרת ומאזין לה או משנה אותה. זה נשמע נורא סייבר סייברי אבל זה בהחלט קורה – או על ידי השכן שהשתלט לנו על הראוטר, בעל בית הקפה או – ברוב המקרים – המדינה שמנסה לצנזר אותנו. המגן והפתרון הוא https שמגן על התקשורת בינינו לבין האתר.

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

אבל אם התקנו – באמצעות הספק שלנו – תעודת SSL באתר – האם כל ההצפנות שוות? האם זה אומר שאנחנו יכולים לנוח על זרי הדפנה? התשובה היא: לא. לא כל תעודות האבטחה תקינות, לא כל השרתים והפרוטוקולים אותו דבר. ישנן תעודות או יישומים של תעודות שיאפשרו התקפת MITM. דוגמה טובה היא התקפת ROBOT שהיא חולשה שיש על השרת ושפותחת פתח ל-MITM. חולשה נוספת וידועה היא שימוש בגורם מאשר לא תקין או שנפסל מסיבות אלו ואחרות או שימוש במפתח הצפנה מיושן שקל לפצח אותו.

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

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

הציון היה נמוך לא בגלל יישום לא תקין של התעודה על השרת, לא בגלל שהתעודה לא חתומה כמו שצריך – אלא בגלל שהשרת תומך בתקן ישן של אבטחה שנקרא TLS 1.0 ו-TLS 1.1. מדובר בפרוטוקול שבעצם מכתיב לדפדפן איך לנהל את תהליך ההצפנה וחילופי המפתחות עם השרת. ובדיוק כמו כל פרוטוקול, יש לו גרסאות כשגרסאות 1.0 וגרסאות 1.1 נחשבות מיושנות. אם השרת תומך בפרוטוקול הזה, תוקפים יכולים לבצע מתקפה באמצעות החולשות בפרוטוקול. איזו מתקפה? MITM ובכך לעקוב אחר הגולשים שנכנסים לאתר או לשנות את תוכנו כפי שהם רואים אותם. בדיוק בשביל זה יש המלצה להשתמש בפרוטקולים טובים יותר של TLS 1.2.

אז למה לא? כי התקן הזה מיושן אבל נדרש על ידי דפדפנים מיושנים – ובייחוד אקספלורר 8-10. אם אני לא אתמוך ב-TLS 1.1, אקספלורר 10 ומטה עלולים שלא לעבוד.

מצד שני, שימוש ב-TLS 1.1 ו TLS 1.0 עלולים לסכן תיאורטית את השאר. אז מצטער גולשי אקספלורר (אין כאלו פה). כי הפרוטוקול הישן הזה עלול להיות מנוצל על ידי תוקפים שיתקפו באמצעותו התקפת MITM. יש כאן קישור מעניין עם הסברים למי שרוצה להעמיק. אבל בגדול – עדיף שלא להשתמש ב-TLS 1.0\1.1. וגם – אפילו אם אני לא חושש מהתקפה כזו – למה לי לשדר חוסר רצינות? גם מראית עין היא חשובה.

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

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

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

אם אתם גם מצאתם משהו באתר שלי (או שרוצים למצוא) – יש בתחתית קישור והסבר על מציאת חורי אבטחה.

פוסטים נוספים שכדאי לקרוא

תמונה של עציץ, רספברי פיי ורמקול
רספברי פיי

לגרום לעציץ שלכם לדבר

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

גלילה לראש העמוד