מה נכלל בהצעת IPsec? שדות IKE ו-ESP
הצעה היא הצעה מלאה אחת, לא שק של אלגוריתמים. ראו אילו שדות שייכים ל-IKE ואילו ל-ESP, ולמה אי-התאמה אחת פוסלת את כל הקבוצה.
IKE מתחיל, שני הקצוות מכריזים על AES, והמנהרה עדיין נכשלת עם NO_PROPOSAL_CHOSEN. היומן מציין את ההצעה אבל לא את השדה שלא התאים. הצעה היא הצעה מלאה אחת, ושדה אחד שאינו תואם פוסל את כל השילוב ולא רק את השורה ההיא. קריאה שלה כשק של בחירות אלגוריתם בלתי תלויות היא הסיבה הרגילה לכך שהאי-התאמה נשארת בלתי נראית.
שני משאים עם רשימות הצעות נפרדות
IKEv2 בונה שני איגודי אבטחה. הראשון הוא IKE SA, שמגן על חילופי הבקרה עצמם, והשני הוא CHILD SA, שנושא את התעבורה שלכם דרך ESP. לכל אחד יש רשימת הצעות משלו, וצד יכול לקבל אחת ולדחות את השנייה.
הפיצול הזה מסביר בלבול נפוץ: IKE SA שעובד מוכיח רק שאלגוריתמי ערוץ הבקרה התאימו. אם הצעת CHILD נכשלת, המנהרה לא נושאת אף מנה, גם כשהשלב הראשון הושלם והיומנים נראים תקינים בחלק העליון.
גם הסדר בתוך כל רשימה חשוב. המשיב בוחר מתוך ההצעות המסודרות של היזם, ולכן העברת רשומה תואמת באופן רחב מעל רשומה צרה משנה איזו ערכה תותקן בלי לשנות אף שם אלגוריתם. קבעו את הסדר הזה בתצורה במקום להסתמך על ברירות המחדל. סדר יציב גם הופך את השוואת היומנים בין אתרים למשמעותית.
אילו שדות שייכים לאיזו הצעה
מערך השדות קטן, אבל הוא אינו זהה בשני המשאים. קראו את הטבלה שורה אחר שורה, כי שדה בעמודה אחת עשוי לחסר בשנייה. התחביר משתנה לפי המימוש; התיעוד של strongSwan להצעות הוא הפניה קונקרטית אחת.
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
שדה ההצפנה מציין את הצופן ובמרבית התחבירים גם את אורך המפתח שלו. שדה השלמות מציין את הגיבוב המשמש לאימות הטקסט המוצפן, וה-PRF מציין את הפונקציה שגוזרת חומר מפתח עבור IKE SA. קבוצת DH יוצרת חומר סודי משותף טרי, ולכן היא מופיעה בשני הצדדים אך למטרות שונות.
מספרי רצף מורחבים שייכים רק לנתיב הנתונים. הם מרחיבים את מרחב הרצף ומנוהלים במשא ומתן כחלק מהצעת CHILD, ולכן אי-התאמה שם פוסלת הצעת CHILD ומשאירה את IKE SA ללא שינוי.
איך נבחרת הצעה מלאה אחת
כל הצעה היא קבוצה, והמשיב מחפש קבוצה שבה כל שדה חובה מקובל. שתי רשימות יכולות להכיל AES ו-SHA-256 ועדיין לא להכיל אף רשומה תואמת, מפני שאורך המפתח, ה-PRF או קבוצת DH שונים. ההשוואה נעשית לכל הצעה, לא לכל אלגוריתם.
כששום דבר לא מתאים, המשיב שולח NO_PROPOSAL_CHOSEN עם סוג ה-SA שנכשל. קראו לאיזו רשימת הצעות מתייחסת ההודעה לפני עריכת התצורה; החלפת אלגוריתמי ESP כשהצעת IKE נדחתה מבזבזת סבב ניפוי שגיאות.
כדאי להכיר את התנהגות הבחירה כשמכווננים פרופיל. מימושים אחדים מעדיפים את סדר היזם, אחרים ממיינים מחדש לפי מדיניות מקומית, ולכן ערכה שעובדת בין שני ספקים יכולה להיעלם כשמהפכים איזה צד מתחיל את החיבור.
AEAD מסיר שדה במקום להוסיף אחד
AES-GCM ו-ChaCha20-Poly1305 מאמתים ומצפינים בפעולה אחת. כשאחד מהם נבחר ל-ESP, אלגוריתם השלמות אינו מנוהל במשא ומתן בנפרד, מפני שמבנה AEAD כבר מכסה אותו. לכן הצעה שמצמדת AES-GCM ל-SHA-256 מיותרת במקרה הטוב ונפסלת במקרה הרע.
ה-PRF נשאר נפרד בצד IKE, מפני שהוא גוזר מפתחות לערוץ הבקרה ולא מגן על המטענים. לכן הצעת IKE יכולה לשלב כדין צופן AEAD עם PRF וקבוצת DH, בעוד הצעת ESP המתאימה מפרטת רק את צופן AEAD ואת קבוצת PFS האופציונלית.
אורך המפתח הוא חלק מאסימון ההצפנה, ולכן AES-128-GCM ו-AES-256-GCM הן הצעות שונות. פרופיל שהועתק ממדריך שהניח מפתחות 256-bit לא יתאים לנקודת קצה שמוגדרת ל-128-bit, אף ששתי השורות אומרות AES-GCM. שני צדדים יכולים להסכים על משפחת הצפנים ועדיין לדחות זה את זה בגלל המספר שאחרי המקף.
קראו את ה-SA המותקן, לא את התצורה
רשימת ההצעות המוגדרת היא הצעה; ה-SA המותקן הוא התוצאה. ב-strongSwan ובליבת Linux שתי התצוגות זמינות:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas מדפיס את האלגוריתמים שנקבעו לכל SA, כולל האם ה-CHILD משתמש ב-AEAD. ip xfrm state מראה מה הליבה התקינה בפועל, ושם מאשרים שחידוש מפתחות לא נסוג לערכה שונה מזו שתיעדתם.
שמרו את הפלט הזה לצד התצורה לאחר תיקון. כשעדכון לקוח משנה את ברירות המחדל שלו, הערכה המתועדת נותנת לכם קו בסיס להשוואה, וההשוואה מצביעה על השדה שזז במקום להתחיל את החקירה מההתחלה.