OpenVPN tls-crypt-v2: מה תפקיד מפתח הלקוח והבלוב העטוף
פרופיל tls-crypt-v2 מכיל מפתח בקרה של הלקוח והעתק עטוף שרק השרת יכול לפתוח. יש להחזיק כל אובייקט וכל שלב פרישה בנפרד.
הדבקת פרופיל tls-crypt-v2 בכרטיס תקלה נראית בלתי מזיקה עד שמספרים מה יש בקובץ. מפתח ערוץ הבקרה של הלקוח יושב לצד עותק מוצפן של אותו מפתח, ואובייקט שלישי, מפתח העטיפה, לעולם אינו יוצא מהשרת המקבל. שלושת אלה עונים על שאלות שונות בנוגע למשמורת, לשיתוף ולפרישה. הפרדה ביניהם מכריעה את רוב המחלוקות המדיניות לפני שהן מתחילות.
מה באמת מכיל הפרופיל
חצי הלקוח של tls-crypt-v2 הוא מפתח ועותק עטוף שלו. הלקוח משתמש במפתח הפשוט להגנת ערוץ הבקרה ומוסר את העותק העטוף לשרת בזמן ההתקנה, כך שהשרת משחזר את אותו מפתח בלי לשמור עותק בטקסט גלוי לכל לקוח. מפתח העטיפה מאפשר את השחזור הזה ושייך רק לצד המקבל. כל מה שלהלן נובע מהמקום שבו שלושת האובייקטים האלה חיים.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
קראו את הטבלה לפי משמורת ולא לפי שם, וההשלכות ייפלו מאליהן. אובדן מפתח העטיפה הוא האירוע היקר, מפני ששום דבר בפרופיל אינו יכול לשחזר אותו וההתאוששות ההוגנת היא הנפקה מחדש של הקבוצה. פרופיל שדלף זול יותר אך נפוץ הרבה יותר, משום שאנשים מדביקים פרופילים בכרטיסי תקלה מתוך אמונה שהעותק העטוף הופך את הקובץ לבטוח לשיתוף. שני הכשלים דורשים תגובות שונות, וזו הסיבה להחזיק את האובייקטים בנפרד.
למה העותק העטוף אינו כל הסיפור
פרופיל נושא את החומר השמיש של הלקוח יחד עם המקבילה העטופה שלו, ולכן הגנה על העותק עבור השרת אינה אומרת דבר על הגנת הקובץ. הבלוב בטוח להעברה ולא בטוח לפרסום. המטא-נתונים שבתוכו גלויים לכל מי שמקבל את הבלוב, כולל כל מי שיקרא מאוחר יותר את כרטיס התקלה שאליו הודבק.
התייחסו לפרופיל כאל אישור גישה ולא כאל דוגמת תצורה. קובץ שדלף נותן למי שמחזיק בו זהות לקוח עובדת עד שהשרת מפסיק לקבל את הזהות הזו, והעטיפה אינה עושה דבר בנוגע לחלון הזה. הנפיקו פרופיל אחד לכל לקוח כדי שהפרישה תישאר החלטה של קובץ אחד, וגבו את מפתח העטיפה בנפרד מתצורת השרת שהוא מאפשר. אף אחת משתי ההרגלים אינה מתקנת פרופיל שנפרץ, אבל שתיהן קובעות באיזו מהירות ייכלל הבא בתור.
היכן יושב וו האימות בתוך לחיצת היד
וו האימות רץ לפני שמחסנית ה-TLS נחשפת, ותפקידו לבדוק את המטא-נתונים שנישאים בבלוב העטוף. הוא מקבל את המטא-נתונים האלה ועוד סביבה קטנה ומתועדת, ויש לו פחות לעבוד איתו מאשר לוו אימות זהות. ההנחה שהוא יכול לראות שמות משתמש, מצב הפעלה או משתני תוספים היא הדרך הרגילה שבה הוו הזה נכתב בצורה גרועה. קראו את פרק המדריך של הוו עצמו במקום לשאול ציפיות מוו אחר.
מצב היציאה שלו הוא ההחלטה: תוצאה שאינה אפס דוחה את הלקוח ותוצאת אפס מאפשרת ללחיצת היד להימשך. לכן המדיניות חייבת לומר מה קורה כשמטא-נתונים חסרים, אינם ניתנים לפענוח או בלתי צפויים. כתבו קודם את מסלול הדחייה, ואחר כך החליטו אילו ערכים מקובלים.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shשתי השורות האלה הן משטח המדיניות בשרת: האחת נוקבת במפתח העטיפה, האחרת נוקבת בתוכנית ששופטת כל לקוח. כל מה שמעניין נמצא בסקריפט, שראוי לבקרת גרסאות ולאותה סקירה כמו כל כלל גישה אחר.
חשבון, תעודה ומפתח בקרה נפרשים בנפרד
קבלה מוקדמת של ערוץ הבקרה אינה אימות, מפני שהיא מתרחשת לפני בדיקת זהות ה-TLS ולפני כל הרשאת חשבון. השבתת חשבון, ביטול תעודה ודחיית מפתח בקרה של לקוח הם שלושה פעלים עם שלושה מנגנונים. פריסה שמבצעת רק אחד מהם יש בה פער ולא מדיניות. יש ליישב את השלושה במכוון, ולתעד איזה שלב מפעיל איזו סמכות.
התזמון הוא ההבחנה השנייה. רשימת קבלה ששונתה חלה על לחיצות יד חדשות, בעוד הפעלות שכבר נוצרו ממשיכות לרוץ עד שמשהו מסיים אותן. ספירת רשומות ברשימה החדשה כהוכחה שהפעלות ישנות הסתיימו היא הדרך שבה לקוח שהוסר נשאר מחובר שעות.
סמכויות שלא יושבו משאירות שני חורים שקל למצוא בפועל. אפשר להשבית חשבון בשעה שמפתח הבקרה שלו עדיין פותח לחיצת יד, ואפשר לבטל תעודה בשעה שמדיניות המטא-נתונים עדיין מקבלת את אותו לקוח. שניהם אותה טעות במקומות שונים, מפני שמפעיל התייחס לרשימה אחת כאל כל הסמכות. הניחו את שלוש הרשימות זו לצד זו בזמן ההסרה והטעות תהפוך גלויה.
הנפקה ופרישה של פרופיל
הנפקה היא החצי הקל: צרו את מפתח הלקוח בצד המקבל, מסרו את הפרופיל לבעלים אחד בדיוק, החזיקו את חומר העטיפה מוגבל, והריצו את אותה תוכנית אימות בכל שרת מקבל. קבלה זולה היא תכונה של כל הקבוצה, לא של המארח החדש ביותר. שרת שני עם סקריפט ישן או רופף יותר הופך בשקט לנתיב החלש ביותר בפריסה.
פרישה דורשת את שלושת השלבים בסדר מכוון. דחו את הלקוח בוו האימות כדי שלחיצות יד חדשות ייכשלו, בטלו את התעודה שלו אם משתמשים ב-PKI, והשביתו את החשבון כדי שלהרשאה מאוחרת לא יהיה מה להרשות. אחר כך סיימו את ההפעלות שהקבלה הישנה התירה, מפני שהן לא יבחינו באף אחד מהשלושה. תרגלו את הרצף על לקוח שאתם יכולים להרשות לעצמכם לשבור.
מטא-נתונים בפרופיל הם קלט למדיניות הזו, לא הוכחה שבקרת גישה כבר קיימת. מסמך העיצוב של OpenVPN 2.6 מתאר את האובייקטים ואת הגבול שהם משרטטים, בעוד שאכיפתם נשארת אצל המפעיל.