🥇DPI (בדיקת SSL) נוגדת את נקודת ההצפנה, אבל חברות מיישמות את זה

שרשרת אמון. CC BY-SA 4.0 יאנפאס

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

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

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

במקום להסתמך על אישורים בחתימה עצמית או אישורים ממכשירי DPI, אתה יכול להשתמש ב-CA ייעודי מרשות אישורים של צד שלישי כגון GlobalSign. אבל קודם כל, בואו נעשה סקירה קטנה של הבעיה עצמה.

מהי בדיקת SSL ומדוע משתמשים בה?

יותר ויותר אתרים ציבוריים עוברים ל-HTTPS. למשל, לפי סטטיסטיקות של Chromeבתחילת ספטמבר 2019, חלקה של התעבורה המוצפנת ברוסיה הגיע ל-83%.

למרבה הצער, הצפנת תעבורה נמצאת יותר ויותר בשימוש על ידי תוקפים, במיוחד מאז Let's Encrypt מפיצה אלפי תעודות SSL בחינם באופן אוטומטי. לפיכך, נעשה שימוש ב-HTTPS בכל מקום - והמנעול בשורת הכתובת של הדפדפן הפסיק לשמש אינדיקטור אמין לאבטחה.

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

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

כיצד פועל תהליך הפענוח/ההצפנה מחדש

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

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

הודעת אזהרה לאישור בחתימה עצמית ב-Chrome. מָקוֹר: BadSSL.com

На компьютерах с Windows можно задействовать Active Directory и групповые политики, но для мобильных устройств процедура сложнее.

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

האפשרות הטובה ביותר: תעודת שורש פרטית ויעודית מ-CA של צד שלישי

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

ארכיטקטורה פשוטה עבור אישורי שורש ייעודיים של לקוח

הגדרה זו מבטלת חלק מהבעיות שהוזכרו קודם: לפחות היא מצמצמת את מספר השורשים שצריך לנהל. כאן אתה יכול להשתמש רק ברשות שורש פרטית אחת לכל צרכי ה-PKI הפנימיים, עם כל מספר של CAs ביניים. לדוגמה, הדיאגרמה שלמעלה מציגה היררכיה מרובת רמות שבה אחד מ-CAs הביניים משמש לאימות/פענוח SSL והשני משמש למחשבים פנימיים (מחשבים ניידים, שרתים, שולחנות עבודה וכו').

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

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

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

הדפדפנים נלחמים בחזרה

יש לציין שמפתחי דפדפנים מנסים להתמודד עם מגמה זו ולהגן על משתמשי הקצה מפני MiTM. למשל, לפני כמה ימים מוזילה קיבל החלטה הפעל פרוטוקול DoH (DNS-over-HTTPS) כברירת מחדל באחת מגרסאות הדפדפן הבאות בפיירפוקס. פרוטוקול DoH מסתיר שאילתות DNS ממערכת DPI, מה שמקשה על בדיקת SSL.

על תוכניות דומות 10 בספטמבר 2019 הוכרז גוגל עבור דפדפן כרום.