למה הוספת opt-verify לא תתקן את שגיאת ההצפנה של OpenVPN

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

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

מה האפשרות אכפה בעבר

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

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

מה עושה 2.7 כשהיא רואה את השורה

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

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

איפה הכשל באמת נמצא

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

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

החלף את הכוונה, לא רק את השורה

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

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

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

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