TLS נוסע בתוך ערוץ הבקרה, ולא בכל המנהרה

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

המעטפה באה קודם

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

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

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

שכבת האמינות שייכת לפרוטוקול

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

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

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

חבילות נתונים משתמשות בפורמט אחר

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

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

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

מדוע פרוקסי HTTPS לא יכול לעזור

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

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

לקרוא עקבה נכון

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

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