האם כדאי לערום שתי שכבות VPN? שלושה תנאים לבדיקה

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

רשמו מה הצופה שומר

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

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

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

תנאי ראשון: האם השכבות נעצרות במקומות שונים?

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

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

תנאי שני: האם חומר המפתחות באמת בלתי תלוי?

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

כאן עוקפת הקמת מפתחות היברידית את ערימת המנהרות. IKEv2 יכול לשאת כמה חילופי מפתחות במשא ומתן אחד, כך שקבוצה קלאסית ו-KEM פוסט-קוונטי יכולים שניהם להזין את אותם מפתחות סשן במקום להיעטף זה סביב זה. התוצאה היא אסוציאציית אבטחה אחת שמפתחותיה תלויים בשני הסודות, והתוקף חייב לשבור את שניהם. זהו מבנה מתועד עם הרכב מוגדר, ומה שערימה תוצרת בית של שני מוצרי VPN אינה. ב-strongSwan, swanctl --list-sas מדפיס את ההצעה שנמשאה ומתנה עבור כל SA, וכך אתם מאשרים מה באמת רץ ולא מה שהגדרתם.

תנאי שלישי: האם הנתונים שורדים את ההנחה החיצונית?

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

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

מה לבנות במקום כשהתשובה היא לא

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

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

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