מה באמת מגן עליו ביטוי סיסמה במפתח פרטי של VPN

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

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

דיאלוג אחד, כמה סודות שונים

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

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

מה ההצפנה בדיסק מכסה

מפתח PEM מוצפן מגיע בשתי צורות, והכותרת אומרת לך איזו יש לך. הצורה המודרנית PKCS#8 מתחילה ב------BEGIN ENCRYPTED PRIVATE KEY-----; צורת PEM הישנה, שעדיין נפוצה בהתקנות OpenVPN ישנות, מתחילה ב------BEGIN RSA PRIVATE KEY----- ונושאת Proc-Type: 4,ENCRYPTED ושורת DEK-Info ממש מתחתיה. הקובץ מחזיק את המפתח הפרטי מוצפן תחת מפתח שנגזר מביטוי הסיסמה שלך, בדרך כלל באמצעות KDF מבוסס סיסמה עם מספר איטרציות או גורם עבודה מוצהר. תיעוד OpenSSL pkey מכסה את הפורמטים ואת אפשרויות ביטוי הסיסמה שחלות בקריאה.

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

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 מציג את הכותרת, ובקובץ ישן את השורות Proc-Type ו-DEK-Info שמוכיחות הצפנה; שורה אחת לבדה אינה הוכחה לאף כיוון. שורת pkey מבקשת את ביטוי הסיסמה ומדפיסה רק את החצי הציבורי, מה שמוכיח שהקובץ וביטוי הסיסמה עובדים בלי לחשוף את המפתח הפרטי. אל תשתמשו ב--text לבדיקה הזו: הוא מדפיס את הרכיבים הפרטיים, privateExponent, prime1, prime2 והשאר, ואסור להדביק את הפלט הזה בשום מקום, לא בכרטיס, לא בצ'אט ולא ביומן. פקודת PKCS#12 גם מספרת לכם אם לחבילה יש סיסמת MAC או הצפנה נפרדת, וזה שווה לדעת לפני שאתם מוסרים אותה לעמית.

מה הוא מפסיק להגן עליו ברגע שהמפתח נטען

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

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

למה ההנחיה ממשיכה לחזור

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

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

אובדן וחשיפה אינם אותו תיקון

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

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