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

קראו את הכשל לפני שתשנו הגדרת אמון כלשהי

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

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

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

בחרו בין אמון במנפיק לבין נעיצת מפתח אחד

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

ApproachGood fitWhat breaks it
Trust the issuing CA with --cafileInternal PKI you can obtain over an already trusted channelCA rotation, or a client that still falls back to public roots
Pin one key with --servercertNo CA relationship, or exactly one key should ever be acceptedAny reissue that generates a new key pair

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

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

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

הנעיצה נוסעת באפשרות תעודת שרת, והקידומת שלה קובעת את הקידוד: תמציות מפתח ציבורי הקסדצימליות תחת sha1 או sha256, ונעיצת מפתח base64 תחת pin-sha256. אספקתה גם מבטלת את אמון המערכת לאותה הרצה, כך שהמפתח הנעוץ הופך להחלטה כולה.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

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

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

התמודדו עם החלפה בלי לנעול את עצמכם בחוץ

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

כתבו את תאריך השינוי לצד הנעיצה. נעיצה בלי תאריך בדיקה היא תקלה עתידית שנושאת הודעת שגיאה מבלבלת.

שללו את גרסת הלקוח לפני עריכת אמון

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

openconnect --version

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

מאמרים קשורים