למה openssl rand לא יכול ליצור את המפתח ש-tls-crypt צריך

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

מה הקובץ בדיסק באמת חייב להיות

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

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

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

הדרך הנתמכת ליצור אחד

צרו את המפתח הסטטי הפשוט בכלי שיצרוך אותו, ואז הפנו אליו משני הקצוות:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

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

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

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

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

איפה בייטים שנעשו ביד נשברים

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

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

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

סבב בלי לנעול את כולם בחוץ

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

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

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