לפרופיל OpenVPN יש שלושה בלוקי תעודה: איזה מהם סודי?

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

קובץ אחד, שלושה בלוקים, תפקידים שונים

פרופיל טיפוסי מטמיע בלוק ca, בלוק cert ובלוק key בין סמני BEGIN ו-END, או מפנה לאותם שלושה כקבצים נפרדים. פרופילים מסוימים מוסיפים בלוק רביעי למפתח tls-auth או tls-crypt, שהוא סוד משותף ולא תעודה. הלקוח קורא כל בלוק לפי ההוראה שממנה אותו, ולכן התוויות חשובות יותר מהסדר שבו הם מופיעים.

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

ההוראות סביב הבלוקים קובעות איך משתמשים בהם. שנו את ca והלקוח סומך על רשות אחרת; שנו cert בלי לשנות key והלחיצה נכשלת באי-התאמה שאין לה שום קשר לאמון.

בלוק ה-CA ציבורי, מפתח ה-CA לעולם לא

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

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

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

תעודות שרת ולקוח מצביעות בכיוונים מנוגדים

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

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

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

שני חלונות שנראים זהים ואינם

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

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

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

מה מוכיחה לחיצה נקייה ומה לא

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

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