למה הצפנה לבדה אינה עוצרת חבילה משוחזרת

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

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

טקסט מוצפן תקף אינו טקסט מוצפן רענן

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

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

לקרוא להשלכת שחזור ככשל פענוח שולח אותך לתת־המערכת הלא נכונה לחלוטין.

מספר רצף וחלון

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

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

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

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

המצב שייך למפתח, לא למארח

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

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

אבחן את הסיבה לפני שתשבית משהו

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

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

מה הבדיקה אינה מבטיחה

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

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