OCSP מול CRL: כיצד כל בדיקת ביטול באמת עובדת

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

שלב 1: מה כל בדיקה מחזירה וכמה זמן היא נשארת שמישה

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

לכן שמירה במטמון היא הדבר הראשון שצריך לקבוע: איזה רכיב מחזיק את העותק, ואיזו תקרה העותק הזה מציית לה. בשער התקרה צריכה להיות nextUpdate פחות מרווח ביטחון, ולעולם לא מה שכותרת מטמון של HTTP מציעה במקרה. openssl crl -in issuer.crl -noout -lastupdate -nextupdate מדפיס את שני התאריכים, ו-רשימה שה-nextUpdate שלה כבר בעבר צריכה להיחשב כחסרה ולא רק כישנה.

שלב 2: לאן התעודה מפנה את הלקוח

תעודת העלה נושאת בדרך כלל שני רמזים: הרחבת נקודת הפצה של CRL ורשומת גישה למידע של רשות עבור OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints מדפיס את הראשון, והשני נמצא תחת סעיף AIA של openssl x509 -in client.pem -noout -text. כל אחת מההרחבות היא מצביע, לא חובה. לקוח שלעולם אינו מיישם בדיקת ביטול יתחבר היטב לתעודה שההרחבות שלה מציינות מגיב שמת לפני שנה.

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

שלב 3: בחרו fail-closed או fail-open לפני התקלה

מגיב שאינו נגיש או רשימה שפג תוקפה מאלצים החלטה: לסרב לחיבור, או לקבל אותו ולתעד את הפער. פקודת המשנה verify של OpenSSL הופכת את הבחירה המחמירה למפורשת, משום שהוספת -crl_check הופכת CRL לא זמינה ל-unable to get certificate CRL ולבדיקה כושלת. כשל רך ברוב הערימות אינו דגל כלל, הוא היעדר הבדיקה, וזו בדיוק הסיבה שהוא נשלח בטעות.

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

שלב 4: הוכיחו שהבדיקה פועלת במקום שבו התעבורה מתקבלת

מצאו את התהליך שמסיים או מאשר את החיבור, ואז שאלו אותו על שורת התצורה שמפעילה בדיקת ביטול. שער שמאמת את השרשרת אך לעולם אינו שואל על ביטול אוכף מדיניות שונה מזו שבמסמכים שלכם, ושום צילום מסך של שרשרת תעודות אינו מוכיח את ההיפך. OpenVPN כותב את האפשרות כ-crl-verify; strongSwan מחזיק חיפושי CRL ו-OCSP תחת תצורת ה-CA, שם מגדירים crl_uris או ocsp_uris. אם אינכם יכולים להצביע על אף אחד מהם, הניחו שהבדיקה חסרה.

תגובת OCSP נחשבת רק כאשר ה-CA המנפיק חתם עליה, או כאשר חתם עליה מגיב שמחזיק בשימוש מורחב במפתח OCSPSigning שהואצל על ידי אותו CA, ולכן תשובה משירות לא קשור אינה מוכיחה דבר. אם אתם מפעילים את המגיב בעצמכם, עקבו אחריו כתלות קשיחה, משום ששירות מת אחד הופך בבת אחת לתקלה לכל לקוח fail-closed.

שלב 5: בטלו תעודה אחת במכוון

קחו תעודת בדיקה, בטלו אותה דרך אותו ערוץ שבו משתמש הייצור, ושאלו את המגיב ישירות. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text אמור לדווח Cert Status: revoked יחד עם זמן ביטול, ותשובה good פירושה שהביטול שלכם לא הגיע למגיב שהלקוחות שלכם שואלים. לאחר מכן הרצו openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem כדי לראות את אותה החלטה דרך מסלול הרשימה. קראו את מחרוזת הסיבה ולא את קוד היציאה, משום שדחיית ביטול ושגיאת שרשרת שתיהן מסתיימות בכשל.

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