ca md too weak: להוציא מחדש את האישור או להוריד את הרמה?

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

מה השגיאה באמת מציינת

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

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

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

תנאי ראשון: האם האובייקט הנדחה הוא השורש?

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

קובצי CA מאוגדים מכילים לעתים קרובות כמה בלוקים, לכן זהו את הבלוק שנטען בפועל במקום להניח שהראשון אשם. הפקודה openssl x509 -in ca.pem -noout -subject -issuer -text מתארת אישור אחד בכל פעם, כלומר יש לפצל את הצרור קודם אם יש בו יותר. השוו את אלגוריתם החתימה המודפס לתקציר שהייתם מצפים לו מתקופת יצירת השורש.

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

תנאי שני: האם אתם שולטים במנפיק?

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

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

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

תנאי שלישי: מה עוד מקבלת הורדת הרמה

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

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

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

ההחלטה, כתובה ככלל

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

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