גרסת TLS לא חוקית ב-AnyConnect בלינוקס: תחילה הגדירו את היקף התיקון

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

קראו את ההודעה לפני שנוגעים במדיניות

שמרו את המחרוזת המדויקת מהחלון. תלונה על גרסה מצביעה על שכבת הפרוטוקול, תלונה על תעודה מצביעה על אמון או שמות, וכניסה שנכשלה מצביעה על פרטי הכניסה. שער שמציע TLS 1.0 עם קבוצת DHE של 1024 סיביות, AES-256-CBC וחתימת SHA-1 יכול להחזיק תעודה תקפה לחלוטין ובכל זאת להידחות על ידי מדיניות מודרנית לפני שפרטי הכניסה שלכם נשלחים בכלל.

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

כשל של openssl s_client -connect vpn.example.com:443 -servername vpn.example.com בעוד -tls1 -cipher DEFAULT@SECLEVEL=0 מצליח אומר שהגבול הוא גרסה וגודל מפתח יחד. אם הפקודה הראשונה מדווחת על מפתח DH קטן ולא על התראת פרוטוקול, הגרסה תקינה ורק הקבוצה דורשת תשומת לב. לעולם אל תכניסו מפתח פרטי או סיסמה לבדיקה.

אפשרות 1: להרפות את כל המארח באמצעות המדיניות הקריפטוגרפית

בפדורה וב-RHEL 8 ו-9, update-crypto-policies --set LEGACY מוריד את מדיניות המערכת של OpenSSL, ו-update-crypto-policies --show מאשר מה פעיל. בדרך כלל זה מחזיר את המנהרה, אך המדיניות נקראת כשתהליך מתחיל, לכן הפעילו מחדש את הלקוח ואת כל תהליך עזר שהוא יצר לפני בדיקה חוזרת. היא גם מתירה פרוטוקולים ישנים יותר וקבוצות חלשות יותר לכל לקוח TLS במכונה, מהדפדפן בחלון הסמוך ועד מנהל החבילות שמעדכן את הליבה.

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

ל-Debian ו-Ubuntu אין מתג אחד לכך. המקבילה היא עריכה של /etc/ssl/openssl.cnf שקובעת MinProtocol נמוך יותר ו-CipherString = DEFAULT@SECLEVEL=0 במקטע ברירות המחדל של המערכת. אותו היקף, קובץ אחר, קצת יותר קל לאבד את המעקב במהלך שדרוג גרסה.

אפשרות 2: קובץ תצורה אחד ללקוח אחד

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

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

כוונו את OPENSSL_CONF לקובץ הזה והפעילו את לקוח ה-VPN דרך עטיפה שמייצאת אותו. כל השאר במארח שומר על מדיניות ברירת המחדל, וזו התכונה שחשובה כשמגיעה שאלת הציות. אשרו שהקובץ באמת בתוקף לפני שאתם מאשימים את השער: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 אמור לפרט צפני TLS 1.0, ותוצאה ריקה פירושה שהשרשרת שבורה והלקוח שמר בשקט על ברירות המחדל של המערכת.

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

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

אפשרות 3: מכונה וירטואלית או מכולות חד-פעמיות

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

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

מה ההשוואה משאירה לכם

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

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