פרטיות OCSP: המשיב רואה תעודה, לא את הכתובת שלך

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

הבקשה מזהה תעודה אחת

מזהה תעודת OCSP נבנה מפונקציית hash, שני hashes של המנפיק ומספר סידורי של תעודת היעד, כפי שמצוין ב-RFC 6960. כל שדה מצביע על תעודה אחת, לא על כתובת או על בקשת HTTP.

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

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

מה המשיב יכול למעשה לצפות בו

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

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

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

סטטוס יכול להגיע מוצמד ב-handshake

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

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

מטמון שובר את ההנחה עמוד אחד חיפוש אחד

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

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

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

בחירות פרטיות ששומרות על האימות שלם

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

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

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