שגיאות TLS רק ב-VPN הארגוני: תקנו את מאגר האמון הנכון

בניית Go, התקנת Composer ולקוח Python כולם עובדים בבית וכולם נכשלים בתוך ה-VPN של החברה. הדפוס הזה אומר לכם משהו על המסלול, לא על היישום. משהו במנהרה שינה את שרשרת האישורים שהתהליך שלכם רואה, או איפס את לחיצת היד לפני שהגיעה שרשרת בכלל. שתי התקלות נראות דומה במסוף ודורשות תגובות שונות לגמרי.

שלוש הודעות, שלושה מנגנונים

השגיאה x509 certificate signed by unknown authority פירושה שנבנתה שרשרת ושהשורש שלה חסר במאגר האמון שבו משתמש אותו תהליך. השגיאה self-signed certificate in certificate chain בדרך כלל פירושה שפרוקסי בדיקה השיב באישור משלו, וזו שרשרת שסביבת ההרצה שלכם אינה מזהה. SSL EOF במהלך לחיצת היד פירושו שהחיבור נסגר לפני שנשלח אישור שמיש כלשהו, וזה התקן תווך שדוחה את ה-ClientHello, ולא בעיית אמון כלל.

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

מצאו את החבילה שהתהליך באמת קורא

השורש הארגוני המותקן במאגר של Windows מתקן דפדפנים ויישומי .NET שפונים למאגר המערכת. הוא לא עושה דבר לבנייה שרצה בתוך מכולה, שנושאת חבילת CA משלה, ולא לתהליך Python שמשתמש ב-certifi או לתהליך Node שמשתמש ברשימה המובנית שלו. Go קורא את מאגר המערכת של הסביבה שבה הבינארי רץ, כלומר המכולה ולא המחשב הנייד. לכן מכונה אחת מייצרת בו-זמנית גם דפדפן שעובד וגם כלי בנייה שנכשל.

שאלו את הכלי במקום להניח. הפקודה python3 -c "import ssl; print(ssl.get_default_verify_paths())" מדפיסה את הקבצים ש-Python יבדוק, והפקודה node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" מראה אם כבר הוגדר עקיפה. עבור מכולה, הריצו את אותה בדיקה בתוך התמונה, כי זו הסביבה שהבנייה באמת משתמשת בה.

התקינו שורש אחד במקום שבו הבנייה רצה

קבלו את שורש הבדיקה ממחלקת ה-IT כקובץ PEM ואמתו את טביעת האצבע שלו בערוץ נפרד לפני שאתם סומכים עליו. בתמונות מבוססות Debian, העתיקו אותו אל /usr/local/share/ca-certificates/ והריצו את update-ca-certificates; תמונות ממשפחת RHEL משתמשות ב-update-ca-trust אחרי שמניחים את הקובץ ב-/etc/pki/ca-trust/source/anchors/. בבנייה של מכולה, הוסיפו את השלבים האלה לפני הפקודה שנכשלת כדי שהשכבה תישמר במטמון מעל התקנת התלויות.

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

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

כשהלחיצה מתה לפני אישור

אם לא מוצג דבר, שום שינוי במאגר האמון לא יעזור. השוו את אותה בקשה עם המנהרה פתוחה וסגורה, ואז בדקו את השרשרת ישירות עם openssl s_client -connect host:443 -servername host -showcerts. חיבור שמסתיים מחוץ ל-VPN ומתאפס בתוכו הוא החלטת מדיניות של התקן התווך, והתרופה היא חריגה עבור אותו מארח ולא אישור נוסף. בקשו לאפשר למאגר החבילות או לנקודת הקצה של ה-API לעבור ללא שינוי.

פיצול המנהרה כך שהכלי יעקוף את ה-VPN מונע בדיקה של התעבורה הזו, מה שעלול להפר מדיניות ולא הופך את הכלי לאמין.

רשמו את התוצאה לכל כלי

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

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