OpenVPN username-as-common-name: מדוע בדיקת ה-CN שלכם ריקה
סקריפט client-connect שמשווה common_name ל-username עלול להשוות שם לעצמו. קשרו את התעודה לחשבון לפני שההחלפה מתבצעת.
אתם מוסיפים סקריפט client-connect שדוחה כל חיבור שבו common_name שונה מ-username, וזה נראה כמו קישור בין תעודה לחשבון. בשרת שמריץ username-as-common-name, ההשוואה הזו כבר איבדה את משמעותה עד שהסקריפט רץ. שני הערכים הם אותה מחרוזת, ולכן הבדיקה עוברת עבור תעודה שהונפקה למישהו אחר לגמרי.
הבדיקה אינה שגויה משום שהסקריפט כתוב רע. היא שגויה משום שהערך שהוא קורא הוחלף קודם לכן באותו חיבור.
מה ההשוואה נראית כאילו היא מוכיחה
אימות תעודה ואימות סיסמה הם הוכחות נפרדות, ושרת יכול לדרוש את שניהם בלי לדרוש שהם שייכים לאותו אדם. הפער אמיתי: תעודת מכשיר תקפה יחד עם כל חשבון תקף היא טענה שונה מאותה תעודת מכשיר יחד עם חשבון אחד נקוב. סקריפט שמשווה common_name עם username נקרא כמו החוליה החסרה בין השניים. הוא היה כזה, אילו common_name עדיין היה אומר את מה שהתעודה אמרה.
האם כך הדבר תלוי באפשרות שרת אחת, ובדרך כלל מפעילים אותה מסיבה לא קשורה, כגון הפיכת קובצי תצורה לכל משתמש לקלים יותר לשמות.
מה username-as-common-name עושה לשם
כאשר username-as-common-name מופעל, OpenVPN מחליף את השם הנפוץ של התעודה בשם המשתמש המאומת לאחר שנבדקו שם המשתמש והסיסמה. וו האימות שרץ במהלך הבדיקה הזו עדיין מקבל את השם הנפוץ של התעודה, משום שההחלפה טרם התרחשה. כל מה שאחר כך, כולל client-connect, רואה את שם המשתמש. כך הקריאה החוזרת המאוחרת מקבלת זהות אחת פעמיים ואינה יכולה להשוות אותה לתעודה שהוצגה.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
עקבו אחר חיבור המחשה אחד: תעודה שהונפקה עבור bob-device, התחברות מוצלחת לספרייה בשם alice, והאפשרות מופעלת. שלב האימות עדיין יכול לראות שתי מחרוזות שונות. שלב החיבור רואה alice ו-alice.
הדוגמה הזו מראה מדוע ההשוואה ריקה. היא אינה מראה שהחיבור היה מתקבל אחרת, משום שאימות התעודה ובדיקת הסיסמה עדיין פועלים בעצמם.
מקמו את הקישור היכן ששתי הזהויות עדיין קיימות
יש לאכוף את הכלל בשלב שרואה את זהות התעודה ואת החשבון בו-זמנית, כלומר בפועל וו אימות שם המשתמש והסיסמה או תוסף שנטען שם. תוסף נתמך שכבר מבצע אימות סיסמה הוא בדרך כלל המקום הנכון להוסיף כלל התאמה, משום שהחלפתו בהשוואת שמות תבטל לחלוטין את בדיקת הסיסמה.
הגדירו את המיפוי לפני שכותבים קוד, משום ששוויון הוא לעיתים נדירות המדיניות האמיתית. תעודה מזהה לעיתים קרובות מכשיר ואילו ההתחברות מזהה אדם, ומכשיר אחד יכול לשרת באופן לגיטימי כמה אנשים. אחסנו את הקשר בצורה שאתם שולטים בהנפקתה, והחליטו מה קורה בשינוי שם, בהנפקה מחדש ובשמות עם סיומת דומיין. הפיכה לאותיות קטנות או הסרת קידומת דומיין בלי להבין את הספרייה עלולה למזג שני חשבונות שנועדו להישאר נפרדים.
זכרו שהאפשרות גם משנה איזו תצורה לכל לקוח חלה, משום ש-client-config-dir ממופה לפי השם הנפוץ.
בדקו את ההתאמה עם שני אישורים תקפים
התחילו בצמד שהמדיניות שלכם מתירה ואשרו שהוא מתחבר. אחר כך הציגו את אותה תעודה תקפה עם חשבון אחר אך תקף אף הוא: הניסיון הזה חייב להיכשל, והוא חייב להיכשל בגלל כלל ההתאמה ולא בגלל סיסמה שהוקלדה בטעות. סיסמה שגויה מוכיחה שבדיקת הסיסמה עובדת ואינה אומרת דבר על הכלל בין התעודה לחשבון.
בדקו גם את מסלולי התעודה החסרה והתעודה הפסולה, ואשרו איזו זהות השרת משתמש בה להגדרות לכל לקוח. אם הדרך היחידה לגרום להשוואה לעבוד היא לכבות את username-as-common-name, תמחרו את השינוי הזה קודם, משום שהוא מחזיר את חיפוש התצורה של כל לקוח לשם התעודה.