מעקב אחר מנות בקרה של OpenVPN: tls-auth לפני TLS

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

קראו את המעטפת בסדר שבו היא נבנית

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

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

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

הראו שהבדיקה מופעלת לפני לחיצת היד

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

העלו את רמת הפירוט של הדמון וצפו בערוץ הבקרה ולא בהתקן tun:

openvpn --config /etc/openvpn/server.conf --verb 6

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

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

התאימו מפתח, כיוון ו-digest בשני הקצוות

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

צרו את הסוד המשותף בכלי ולא בעורך, ושמרו על הרשאות הדוקות:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

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

שחזרו תג רק מהפורמט האמיתי

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

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

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

בטלו אי-התאמה בלי להסיר את ההגנה

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

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

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