0x או 0s? פענוח תבנית PSK בקובץ ipsec.secrets

לקוח אחד מאמת את עצמו עם המפתח המשותף ואחר דוחה אותו, בעוד התווים שהדבקת נראים זהים משני הצדדים. סביר להניח שאלה אותם תווים; ההבדל הוא איזו כלל פענוח הקובץ מיישם עליהם. מחרוזת בין מרכאות נלקחת ככתבה וכלשונה, אסימון שמתחיל ב-0x נקרא כהקסדצימלי, ואסימון שמתחיל ב-0s נקרא כ-Base64. רק אחת משלוש הכתיבות האלה אומרת את מה שהתכוונת, ולכן התיקון הוא בדרך כלל המרה ולא סיסמה טובה יותר.

התסמין מצביע על קידוד, לא על צפנים

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

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

סוד אחד, שלוש דרכים שבהן הקובץ יכול לקרוא אותו

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

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

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

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

מאין מגיע טקסט Base64

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

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

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

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

ודא אילו בייטים כל עמית באמת משתמש

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

טען מחדש במקום להפעיל מחדש כשהקובץ נכון. ipsec rereadsecrets מרענן את העותק של דימון IKE, והתקנת swanctl טוענת פרטי כניסה בפקודה משל עצמה. הפעלה מחדש מפילה כל אסוציאציה מבוססת ומשמידה את ההשוואה שניסית לעשות.

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

שנה את הקובץ בלי להסתיר את התוצאה

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

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