P12 ישן נכשל ב-OpenSSL 3: סיסמה שגויה או צופן מיושן?
הבחינו בין ביטוי סיסמה שהוקלד בטעות לבין חבילת RC2 ישנה ש-OpenSSL 3 מסרב לפרוק, ואז חתמו מחדש את הקובץ בלי להסיר את הגנת המפתח.
תיבת ההייבוא לוקחת את הסיסמה שלכם, מסתובבת לרגע ואז אומרת שהיא לא יכולה לקרוא את החבילה. שום דבר בהודעה הזו לא אומר לכם אם הקלדתם את ביטוי הסיסמה בטעות או שהקובץ נחתם בצופן שהלקוח כבר לא מספק. אלו כשלים שונים עם תיקונים שונים, והבחירה השגויה מובילה לשנמוך גרסת הלקוח שרק דוחה את ההחלטה. התבוננות בשלב שבו הלקוח עוצר מפרידה ביניהם בכדקה בערך.
מה קורה בין תיבת הדו-שיח לרשימת התעודות
קובץ .p12 הוא מכל, לא תעודה. בפנים יש שקית תעודות אחת או יותר ושקית מפתח פרטי מוצפנת במפתח שנגזר מהסיסמה שלכם, ובנוסף בדיקת שלמות שנקראת MAC על כל הקובץ. לפתוח אותו פירושו לאמת את ה-MAC הזה, לפענח את שקית המפתח ולהתאים את התעודה למפתח שיוצא ממנה.
בעיית סיסמה מגיעה בשלב ה-MAC. בעיית צופן מגיעה מאוחר יותר, כשצריך לפרוק את שקית המפתח והבנייה שעושה זאת אינה כוללת מימוש לאלגוריתם הנקוב בקובץ.
המקרה השני נפוץ במערכות מודרניות מפני ש-OpenSSL 3 העביר קבוצה של אלגוריתמים ישנים לספק legacy אופציונלי. חבילות שיוצאו על ידי OpenSSL 1.x חתמו בדרך כלל את התעודות ב-RC2 של 40 סיביות ואת המפתח הפרטי ב-Triple DES תלת-מפתחי. בנייה ברירת מחדל של OpenSSL 3 עדיין מאמתת את ה-MAC עם הסיסמה הנכונה ואז נכשלת בשקית, כך שהסיסמה מעולם לא הייתה שגויה והקלדתה מחדש לא משנה דבר.
קראו את המכל בלי לכתוב מפתח החוצה
בקשו מהבנייה של OpenSSL במחשב שלכם לנתח את הקובץ ולקרוא את הנקודה שבה היא מוותרת. בדיקה בלי קובץ פלט משאירה את המפתח מוצפן בדיסק, וזו הסיבה היחידה שהשלב הזה בטוח במארח משותף.
openssl pkcs12 -in vpn-identity.p12 -info -nooutבחבילת legacy עם הסיסמה הנכונה זה מדפיס את מאפייני השקית ואז עוצר עם digital envelope routines::unsupported. עם סיסמה שגויה תקבלו Mac verify error: invalid password? לפני שנקראת שקית כלשהי. שתי ההודעות מצביעות לכיוונים מנוגדים, וזה בדיוק המידע שהלקוח הסתיר.
אם הכשל הוא זה של האלגוריתם שאינו נתמך, הריצו את אותה פקודה שוב עם -legacy נוסף ובלי לשנות דבר אחר. הדגל הזה טוען את ספק ה-legacy רק עבור התהליך הבודד הזה. הוא לא גורם ללקוח ה-VPN לנתח חבילות ישנות, לא נוגע במדיניות ההצפנה של המערכת, והוא מדידה ולא תיקון, כי הקובץ עדיין חייב להיות מוחלף.
איזו שגיאה מציינת איזה שלב
טבלה קצרה מפרידה בין שלוש התוצאות, והנוסח חשוב יותר מהמקום שבו הופיעה תיבת הדו-שיח.
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
טקסט כמו not enough data או header too long אינו שייך לאף אחת משתי הקבוצות הראשונות. זו בעיית תבנית: קובץ DER ששמו שונה ל-.pem, עותק שנהרס על ידי עורך שכתב מחדש סופי שורות, או הורדה לא שלמה. השוו את סכום הבדיקה לזה ששלח המנפיק לפני שתתחילו להסתכל על צפנים.
התייחסו ל-Mac verify error כראיה לגבי הסיסמה בלבד. פירושו שה-MAC שחושב ממה שהקלדתם אינו תואם לערך השמור, וזה קורה בגלל שגיאת הקלדה, סיסמה שנשמרה במטמון מהייבוא קודם, או קובץ שיוצא מחדש תחת ביטוי סיסמה אחר. הוא לא אומר דבר על כך אם האלגוריתמים שבפנים ישנים.
בנו חבילה שהלקוח באמת יכול לפתוח
לאחר שמנתח ה-legacy מאשר שהקובץ תקין, התיקון הקבוע הוא החלפה שהלקוח היעד תומך באלגוריתמים שלה: AES-256-CBC לשקיות המפתח והתעודות, PBKDF2 עם SHA-256 לגזירה ו-SHA-256 ל-MAC. מנהל ה-PKI שלכם יכול לייצא זאת מאותו חומר מפתח, והתעודה שבפנים נשארת זו שהשרתים שלכם כבר סומכים עליה.
כשאתם חייבים להמיר מקומית, בקשו מכלי pkcs12 לחתום מחדש את השקיות במקום לרוקן אותן קודם. החזיקו את שני ביטויי הסיסמה מחוץ להיסטוריית ה-shell על ידי קריאתם מקובץ.
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passהמרה מוצלחת לא אומרת דבר על תפוגה, שימוש במפתח, התאמת המפתח הפרטי או אם השרת סומך על שרשרת ההנפקה. אריזה מחדש היא שינוי תחבורה, לא חידוש, וכל אחד מאלה עדיין צריך בדיקה משלו.
דלגו על כל מתכון שכותב מפתח ביניים לא מוגן או סיסמת פלט ריקה רק מפני שהלקוח קיבל לאחר מכן את הקובץ. חבילה קריאה שהוסרה ממנה ההגנה היא תוצאה גרועה יותר מכשל ההייבוא שאיתו התחלתם.
ודאו שהלקוח ייבא את הקובץ שבניתם
ניתוח נקי במסוף מוכיח שהמכל תקין. הוא לא מוכיח שהלקוח בחר בו, מפני שפרופיל שנשאר יכול להמשיך להצביע על הקובץ הישן, וקיימים לקוחות ששומרים במטמון זהות מיובאת תחת שם שלא בחרתם.
הדפיסו את הזהות שאתם עומדים לייבא והשוו אותה למה שהלקוח מציג בתצוגת התעודות שלו.
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256הסירו קודם את רשומת הפרופיל הישנה, ואז ייבאו. אם הלקוח רושם ביומן את הנושא או טביעת האצבע שהוא טען, התאימו אותם לשורה למעלה; אם הוא מציג רק שם ידידותי, בדקו במקום זאת את תאריך התפוגה, מפני שקשה יותר לבלבל בינו לבין תעודה אחרת מאותו מנפיק.
אסמכתת PKCS12 מפרטת את אפשרויות הספק, ביטוי הסיסמה והפלט שבשימוש כאן. הנקודה היא להשאיר את ספק ה-legacy מחוץ לסביבת הלקוח: למדוד איתו, לשלוח בלעדיו, ולהשאיר את המפתח הפרטי מוגן בדיסק.