מפתח IPsec משותף מראש: הבתים שמאחורי המחרוזת שהקלדתם

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

מה השער עושה עם המחרוזת

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

לכן השאלה השימושית אינה לעולם «האם אלה נראים אותו דבר» אלא «איזה רצף בתים מדויק כל מימוש מגבב».

מאין מגיעים בתים נוספים

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

השוו בכלי שמציג בתים ולא גליפים. printf '%s' "$PSK" | xxd | tail -2 מדפיס את סוף הערך בהקסדצימלי, שם 0a או 20 תועה בולט לעין. עשו זאת בשני הצדדים והשוו את שתי ההדפסות זו לצד זו. עשו זאת בחומר בדיקה שנוצר, ולא בסוד ייצור שאחר כך משאירים בהיסטוריית המעטפת.

מקודד אינו מוצפן

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

מילון ה-IPSec של Apple הוא דוגמה שימושית לכך שהסוג חשוב: הוא מתעד את SharedSecret כנתונים עבור שיטת האימות בסוד משותף במטעני L2TP ו-Cisco IPsec. זו תכונה מסוימת במטען מסוים, לא שדה טקסט כללי שאפשר להשתמש בו מחדש עבור פרוטוקול אחר שמבקש סוד במקרה.

מגבלה נטענת שייכת לצירוף אחד

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

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

תקנו את הייצוג, לא את החוזק

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

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