OpenVPN: tls-ciphersuites מול tls-version-min — מה כל אחת מהן אוכפת
רשימת חבילות TLS 1.3 אינה מגבילה את גרסת הפרוטוקול, ו-show-tls מציג רק תמיכה מקומית. בדקו בנפרד את המדיניות, את החבילות ואת התוצאות שסוכמו.
שלוש עובדות שונות נדחסות לשורה אחת ברוב הדיונים על OpenVPN ו־TLS: מה גרסת הלקוח שלכם מסוגלת לעשות, מה הפרופיל מתיר, ומה הגישה בפועל סוכמה. רשימה קצרה של חבילות TLS 1.3 עונה רק חצי על השאלה האמצעית, והיא אינה אומרת דבר על רצפת גרסת הפרוטוקול. עברו על הבדיקות שלמטה לפי הסדר ועצרו בראשונה שאינה מחזיקה, מפני שכל בדיקה מאוחרת יותר מניחה שהקודמות כבר הוכרעו.
בדקו את הגרסה לפני שאתם קוראים רשימה כלשהי
הנחיית תצורה אינה יכולה להוסיף תמיכת פרוטוקול לקובץ בינארי שאין בו כזו. התחילו בבאנר הגרסה, שמציין את ספריית ההצפנה שהודרה:
openvpn --version
גרסת 2.6 המקושרת ל־OpenSSL מקבלת גם tls-cipher וגם tls-ciphersuites. גרסה עם mbed TLS אינה כוללת בחירת חבילות TLS 1.3 כלל, והמדריך של 2.6 מסמן את tls-ciphersuites כאפשרות של OpenSSL. אם השרת נבנה מחדש עם backend אחר, אותו פרופיל יכול לשנות את התנהגותו בלי שאף שורה של תצורה תשתנה.
בעודכם כאן, הריצו את openvpn --show-tls ושמרו את הפלט. זהו המלאי שאיתו תשוו בהמשך, וזול ללכוד אותו לפני שמישהו מתחיל לערוך פרופילים.
כתבו את הבאנר ואת הרשימה לכרטיס השינוי, לא לחלון צ'אט. כששני אנשים חלוקים בשאלה אם לקוח יוכל להציע חבילה בעוד שישה שבועות, הפלט שנלכד מכריע זאת בשורה אחת.
הפרידו בין גבולות הגרסה לרשימות ההצפנה
במדריך 2.6 אלה שלושה בקרות, לא אחת:
tls-cipherקובע את מדיניות ההצפנה ל־TLS 1.2 ולגרסאות קודמות, והוא מועבר לרשימת ההצפנה של OpenSSL;tls-ciphersuitesבוחר חבילות TLS 1.3;tls-version-minו־tls-version-maxמגבילים את גרסאות הפרוטוקול שהחיבור רשאי להשתמש בהן.
לכן רשימת חבילות TLS 1.3 מהודקת היטב אינה מוכיחה דבר על כך שגרסה ישנה יותר עדיין מותרת. אם הדרישה היא „TLS 1.3 בלבד“, רצפת הגרסה היא שנושאת אותה, ורשימת החבילות רק מצמצמת את האפשרויות בתוך הרצפה הזו:
tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
הזוג הזה עושה שני תפקידים. מחיקת אחת השורות משאירה את האחרת אוכפת פחות ממה שנדמה לכם, וזה בדיוק הכשל שכל הבדיקה הזו קיימת כדי לתפוס.
ערוץ הנתונים הוא בקרה רביעית. data-ciphers מנהל משא ומתן על ההצפנה הסימטרית בתוך המנהרה, והתוצאה שלו אינה אומרת דבר על גרסת ה־TLS של ערוץ הבקרה. לראות AES-256-GCM בסיכום הגישה אינו ראיה ל־TLS 1.3 בשום כיוון.
קראו את show-tls כמלאי מקומי
--show-tls מפרט את החבילות שנתמכות על ידי ספריית ההצפנה שאליה קובץ בינארי זה מקושר, לפי סדר עדיפות. זה אינו דוח מהשער. המדריך אומר במפורש שהרשימה מגיעה מהספרייה המקומית, כלומר מחשב נייד עם OpenSSL 3.x ונתב עם גרסה ישנה יותר ידפיסו רשימות שונות כשהם מדברים עם אותו שרת.
| Evidence | What it actually describes |
|---|---|
--show-tls output | Capabilities of this client build and its library |
| Profile directives | What this attempt is allowed to offer |
| Session log line | What this one negotiation selected |
נניח שלקוח תומך בחבילות A, B ו־C וגישה אחת בוחרת ב־B. זה אינו קובע דבר בשאלה אם השרת מתיר A או C, ואף לא אם B היא בחירתו היחידה המותרת. שמרו על שלוש השורות בנפרד, ורוב שיחות ה־TLS המבלבלות ייפתרו מעצמן.
עדיין כדאי לשמור את המלאי. כשגישה נכשלת, השוואה בין רשימת הספרייה לרשימת הפרופיל מראה אם ללקוח היה בכלל סיכוי להציע את מה שהשרת רצה. היא גם מראה אם שינוי ב־backend הסיר בשקט את TLS_CHACHA20_POLY1305_SHA256 מהמאגר שהלקוחות הישנים תלויים בו — סוג הרגרסיה שמתגלה כקומץ משתמשים שאינם מצליחים להתחבר בעוד כל השאר לא מבחינים בדבר.
שאלו את השער משהו שהוא יכול לענות עליו
אם אתם מנהלים את השירות, בדקו את התצורה האפקטיבית של המופע הרץ ולא קובץ בדיסק. ייתכן ש־OpenVPN הופעל עם נתיב --config אחר, שהוא מושך קבצים כלולים, ושהוא לא הופעל מחדש מאז העריכה. המדיניות של הדמון הרץ היא מה שהלקוחות פוגשים.
אם אינכם מנהלים אותו, בקשו מהמפעיל דרישות לקוח נתמכות או מבחן קבלה מוגדר. ניסיון שנדחה אינו בהכרח חבילה שנדחתה: רצפת גרסה, בדיקות זהות תעודה כמו remote-cert-tls, או אי־התאמה בין tls-auth ל־tls-crypt יכולות לסיים את החליפין לפני שבחירת החבילה בכלל חשובה. קראו את שגיאת השרת לפני שתשנו את רשימת הלקוח, מפני ש„handshake failed“ מכסה ארבע סיבות שונות ורק אחת מהן היא אי־התאמת הצפנה.
הפניית openssl s_client אל פורט ה־VPN גם היא אינה משחזרת את השאלה. ערוץ הבקרה פועל בתוך המסגור של OpenVPN עצמו, ולכן בדיקת TLS גולמית בוחנת פרוטוקול אחר בפורט שמצפה למשהו אחר. כל מסקנה שנגזרת ממנה עוסקת בבדיקה, לא במנהרה.
תעדו שתי תוצאות ושמרו עליהן בנפרד
גישה מורשית חדשה מפיקה שורה של ערוץ הבקרה שמציינת את גרסת הפרוטוקול ואת ההצפנה שנבחרה, ושורה נפרדת של ערוץ הנתונים שמציינת את הצפנת המנהרה. לכדו את שתיהן עם גרסת הלקוח ושם הפרופיל, וציינו איזה מופע שרת השיב:
openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt
אחר כך קראו את שתי השורות מהקובץ הזה ולא מהזיכרון. הזוג הוא הראיה; שם חבילה לבדו הוא העדפה, וגבול הגרסה הוא הצהרה נפרדת על מה שהשרת מסרב לו.
בצעו את הבדיקות בסדר הזה. אשרו את הגרסה וה־backend באמצעות --version. לכדו את --show-tls לפני שתשנו משהו. הצהירו על רצפת הגרסה הנדרשת בנפרד מרשימת החבילות. אשרו את המדיניות האפקטיבית של המופע הרץ עם הבעלים שלו. צפו בגישה מורשית אחת ואם התוכנית מאפשרת, בניסיון נדחה אחד עם גרסה ישנה. תעדו את תוצאות ערוץ הבקרה וערוץ הנתונים כממצאים נפרדים.
אם לקוח נדרש אינו יכול לעמוד במינימום חדש, קבלו את החלטת ההעברה או החריגה במפורש במקום להוריד בשקט כלל קבלה לא קשור כדי שהפריסה תיראה גמורה.