האם תעודת VPN שנשללה עדיין מתחברת? בדקו את אכיפת ה-CRL
תעודות שנשללו עדיין מתחברות כאשר ה-CRL אינו מגיע לעולם למאמת. בדקו לפי הסדר את המנפיק, המספר הסידורי שנטען, התנהגות הטעינה מחדש והסשנים הפעילים.
שללתם את התעודה, יצרתם רשימה חדשה, והפרופיל הישן עדיין מעלה מנהרה. השלילה עצמה אינה שבורה: CRL הוא הצהרה חתומה שמספר סידורי אינו תקף עוד, והוא משנה גישה רק כאשר הרכיב שמסיים TLS טוען אותו, עבור המנפיק הנכון, לפני שהוא מקבל את החלטת הקבלה. שם נמצאים רוב המקרים האלה, ולכן שלילה ודחייה הן שתי עובדות נפרדות.
עברו על חמש הבדיקות שלמטה לפי הסדר, ועצרו בראשונה שאינה מתקיימת, כי כל בדיקה מאוחרת מניחה שהקודמות נכונות.
בדקו איזה רכיב מקבל את החלטת הקבלה
תנו שם לתהליך שמאמת את תעודת הלקוח, כי רק אותו תהליך יכול לאכוף רשימה. בשרת OpenVPN זה הדמון עצמו, מוגדר עם crl-verify. ב-ocserv זה השורה crl ב-ocserv.conf. ב-strongSwan הקלט הוא ה-CRLים שנטענו יחד עם strictcrlpolicy. פרוקסי או התקן שמסיים TLS לפני ה-VPN יכול גם הוא להיות המאמת האמיתי, ואם כן, הדמון שמאחוריו לא רואה לעולם את תעודת הלקוח.
WireGuard שייך לקטגוריה אחרת. אין לו תעודות ואין רשימת שלילה; עמית מתקבל לפי המפתח הציבורי שלו בקונפיגורציה, ולכן סיום גישה משמעו הסרת המפתח הזה. אם אתם מחפשים CRL בפריסה של WireGuard בלבד, המנגנון הזה אינו שם.
היזהרו גם מהמלכודת בצד הלקוח. לקוח שמסרב להתחבר מפני שאינו אוהב את תעודת השרת אוכף את השרשרת של השרת, ולא שולל את האישורים של עצמו. תעודת משתמש נשללת רק במקום שבו התעודה הזו מאומתת, וזה כמעט תמיד בצד השרת.
בדקו עבור איזה מנפיק נחתמה הרשימה
CRL מוגבל ל-CA מנפיק אחד. עם שורש ו-CA ביניים, תעודות העלים מגיעות מהביניים, ולכן הרשימה שחשובה היא ה-CRL של הביניים; הרשימה של השורש לא אומרת דבר על העלים האלה. מאמת שמצביע על הקובץ הלא נכון מנתח אותו בשמחה, לא מוצא רשומה מתאימה ומקבל הכול.
אשרו את ההתאמה לפני שנוגעים בדמון. המנפיק בתעודה חייב להתאים ל-subject של הרשימה:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateכאשר שניהם מגיעים מאותו CA, המספר הסידורי שהודפס עבור התעודה הוא הערך שחייב להופיע ברשימה. אם הם אינם תואמים, יש לכם את ה-CRL הלא נכון או את העותק הלא נכון שלו.
התוקף שייך לאותה בדיקה. nextUpdate בעבר הופך את הרשימה למיושנת, ומאמת שנכשל סגור ידחה אז כל לקוח במקום רק את זה שנשלל.
בדקו שהמספר הסידורי נמצא בעותק שהדמון טען
שלילה כותבת רשומה במסד הנתונים של ה-CA, ויצירה מחדש כותבת קובץ חדש. אף אחת מהפעולות לא מגיעה לדמון שרץ וטען את העותק הישן בעת האתחול. הריצו dump לרשימה וחפשו את המספר הסידורי:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlלאחר מכן בדקו כיצד המימוש שלכם קולט את הקובץ. OpenVPN קורא נתיב שניתן ל-crl-verify פעם אחת באתחול, ולכן רשימה חדשה דורשת הפעלה מחדש או אות הפעלה מחדש; אותה אפשרות המופנית לתיקייה נקראת מחדש בכל חיבור, ולכן קיים מצב התיקייה. strongSwan צריך לטעון מחדש את האישורים שלו, למשל עם swanctl --load-creds. העובדה שהקובץ בדיסק נכון והעובדה שהמאמת משתמש בו הן שתי עובדות שונות.
בדקו את המדיניות לרשימה חסרה או שפג תוקפה
זו ההחלטה שהרבה פריסות לא מקבלות אותה במפורש מעולם, והיא מחליטה אם השלילה מגנה עליכם או נועלת את כולם בחוץ. Fail-closed פירושו שבלי מידע שלילה שמיש מתקבלת דחייה; fail-open פירושו שהמאמת ממשיך בלעדיו. strongSwan חושף את הבחירה כ-strictcrlpolicy. OpenVPN עם crl-verify מסרב לעלות על קובץ שהוא לא יכול לקרוא או לנתח, ורשימה שפג תוקפה מופיעה כשגיאת אימות TLS על CRL שפג תוקפו ולא כקבלה שקטה.
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
לכל כיוון שתבחרו, האוטומציה חשובה יותר מהבחירה: משימה שמחדשת את ה-CRL לפני nextUpdate, והתראה כשהעותק שנפרס מזדקן, מונעות משתי המדיניות להפוך לתקרית. בדיקה מקוונת עם OCSP מעבירה את הטריות למגיב, אבל אותו כלל חל, כי מאמת שלא הוגדר לבדוק את התשובה לא משנה דבר.
בדקו את הסשן הפעיל, ואז את העותקים של המפתח
שלילה מוערכת במהלך אימות התעודה, שמתרחש בחיבור ובמשא ומתן מחדש. סשן מבוסס ממשיך לפעול עד שהוא מנהל משא ומתן מחדש, וברירת המחדל של OpenVPN היא פעם בשעה עם reneg-sec 3600. אם האדם חייב לצאת מהרשת עכשיו, סיימו את הסשן בנוסף לפרסום הרשימה, ואז אשרו שההתחברות מחדש נדחית.
הפרידו את האישורים מהעותקים שלהם. מחיקת פרופיל במחשב נייד אחד אינה מונעת מעותק אחר של אותו מפתח פרטי להזדהות; השלילה היא מה שהופך כל עותק לחסר תועלת, ורק כאשר הבדיקות הקודמות מתקיימות. תנו להתקן חלופי תעודה משלו כדי שאחד יוכל להישלל בלי לגעת בשני.
לפני שמכריזים שזה נגמר: הרכיב המאמת זוהה, המנפיק של הרשימה תואם למנפיק של העלה, המספר הסידורי שנשלל נמצא בעותק שהדמון באמת טען, המדיניות לרשימות חסרות או שפג תוקפן מכוונת ומנוטרת, והסשן הפעיל הופסק ולא הומתן. הפורמטים שמאחורי כל זה מפורטים ב-RFC 5280.