בקשת מפתח OpenVPN אחרי OpenSSL 3: בדקו את הספק

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

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

בדקו אם המפתח מוצפן

קראו את השורה הראשונה של הקובץ ואז הניחו לספרייה לנתח אותו, כי שם קובץ לא מוכיח דבר. בלוק PEM עם התווית ENCRYPTED PRIVATE KEY הוא PKCS#8 מוצפן, ובלוק RSA PRIVATE KEY ישן יותר שנושא Proc-Type: 4,ENCRYPTED הוא הצורה המסורתית, ושניהם מצפים למילת מעבר. בלוק PRIVATE KEY שאינו מוצפן לא אמור לבקש כזו בכלל. הריצו את הניתוח בחשבון שמחזיק בקובץ, כי בעיית הרשאות מפיקה שגיאה אחרת והרבה פחות מעניינת.

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

בדקו אם הבנייה הזו יכולה לפענח אותו

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

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

בדקו את התיקון הצר ביותר הזמין

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

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

בדקו את הקשר השירות, ואז קדדו מחדש

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

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

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

בקשה היא תסמין עם לפחות שלושה גורמים, ורק אחד מהם הוא מילת מעבר חסרה.