AH או ESP? החלטה לפי מה שהחבילה חייבת להגן עליו

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

מה AH מכסה ו-ESP לא

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

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

NAT הופך את הבחירה לאילוץ

תרגום כתובות משכתב את המקור או היעד בכותרת ה-IP ש-AH זה עתה אימת, ולכן בדיקת השלמות נכשלת בקצה הרחוק, והיא נכשלת כשגיאת פרוטוקול ולא כהודעה שאפשר לקרוא. ESP אינו מאמת את הכותרת החיצונית, ולכן ESP עם מעבר NAT עובד ו-AH מאחורי NAT לא. מנהרה ששני צדדיה מאחורי נתבים רגילים היא בדיוק המקום שבו זה מופיע ראשון. לכן השאלה הראשונה אינה איזה פרוטוקול חזק יותר, אלא אם יש מתרגם בין הצדדים.

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

המצב מכפיל את השאלה

ESP במצב תעבורה מגן על המטען של השכבה העליונה ומשאיר את כותרת ה-IP בשקט; במצב מנהרה הוא עוטף את כל החבילה הפנימית, כולל כותרת ה-IP הפנימית, ומגן עליה. ל-AH אותם שני מצבים, ולכן AH או ESP הם למעשה ארבעה שילובים לפני בחירת אלגוריתם כלשהו.

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

התחליף הכנה ל-AH בלבד

גרסת ESP לשלמות בלבד שומרת על האלגוריתם ומוותרת על טענת ההצפנה במקום לזייף אותה, והיא עוברת NAT. אם עיצוב ישן השתמש ב-AH מפני שנדרש אימות בלי סודיות, הגרסה הזו היא התרגום הישיר, ולא מנהרה מוצפנת עם הערה מצורפת.

גם לראות ESP בהצעה אינו הוכחה להצפנה. קראו את אלגוריתם ההצפנה: רשומת NULL פירושה שלמות בלבד, ורשומה במצב משולב פירושה את שניהם.

החליטו בשלוש שאלות

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

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

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