tls-auth מול tls-crypt: מה כל אחד מהם מגן עליו ב-OpenVPN

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

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

מה המפתח המשותף באמת מגן עליו

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

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

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

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

היכן שתי האפשרויות נבדלות

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

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

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

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

מדוע אי-התאמה נראית כאילו שום דבר לא קורה

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

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

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

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

מה עדיין צריך להגדיר בנפרד

האפשרויות האלה לא מאמתות מי הצד השני. אימות תעודות, עוגן האמון ושם השרת המצופה נשארים דרישות נפרדות, ואף אחת מהם לא הופכת לרשות משום שיש מפתח משותף.

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

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