האם לחיצת יד VPN שנכשלה היא באמת מתקפת שנמוך?

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

מה מתקפת שנמוך באמת משנה

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

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

למה המשא ומתן עצמו חייב להיות מאומת

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

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

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

תאימות מוגדרת אינה מתקפה

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

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

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

קראו את הכשל לפני שאתם נותנים לו סיבה

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

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

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

אשרו מה נבחר בפועל

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

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

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