האם VPN בתשלום יכול לאשר הפעלות בלי החשבון שלך?
אסימונים שאינם ניתנים לקישור יכולים להפריד את בדיקת הזכאות מההפעלה עצמה. מה שקובע הוא תכנון ההנפקה והמימוש, לא התווית במסך הכניסה.
תשלום עבור מנהרה לא חייב להיות הצגת זהות החיוב בכל חיבור. תכנון יכול לבדוק זכאות פעם אחת, למסור ללקוח אסימונים קריפטוגרפיים, ולהשאיר לשער לקבל אסימון מאוחר יותר בלי לראות את החשבון שמאחוריו. אם זה באמת מסתיר משהו תלוי בהחלטות ההנפקה והמימוש, לכן התייחס לזה כתרגיל אפיון בארבעה חלקים ולא כתכונה שמדליקים.
הפרד את שלב הרכישה משלב ההפעלה
ארכיטקטורת Privacy Pass ב-RFC 9576 נותנת את אוצר המונחים: לקוח, מאשר, מנפיק ומקור. הלקוח מוכיח תכונה כלשהי בפני המנפיק ומקבל אסימונים; מאוחר יותר הוא מציג אחד למקור, שמחליט אם לשרת אותו. כשהיא מיושמת ב-VPN, התכונה המאושרת יכולה להיות יחידת גישה אחת.
החיוב עדיין רואה את מה שהתהליך שלו דורש, ואיש לא טוען אחרת. המטרה הצרה יותר היא שהמימוש המאוחר לא יוכל להיקשר לרכישה שיצרה את האסימון. זו תכונה מוגדרת שאפשר לבדוק, ואותה שווה לרשום.
מחרוזת נשיאה שנראית אקראית לא מספקת את זה. אם המנפיק מאחסן את הערך לצד רשומת לקוח והשער יכול לבקש את המיפוי הזה, שתי האינטראקציות מקושרות באמצעות מסד נתונים ולא באמצעות קריפטוגרפיה. המבנה חייב להפוך את המנפיק לבלתי מסוגל לענות על השאלה הזו, והפריסה חייבת למנוע מהמנפיק ומהשער לאחד את נקודות המבט שלהם.
החלט מה מאשר אסימון אחד
«אסימון אחד קונה גישה» כמעט לא עונה על דבר ברמה התפעולית. האם היחידה היא חיבור אחד, הקצאת זמן או נפח? האם לקוח שאיבד את התשובה שלו יכול להמשיך באותה הרשאה? מה קורה כשמכשיר מתחבר מחדש בזמן שינוי רשת? התשובות האלה קובעות אם התכנון שמיש, ולכל אחת מהן יש השלכה לפרטיות.
| Reuse rule | What it buys | What it leaks |
|---|---|---|
| Single use per connection | Strongest unlinkability between sessions | Frequent reissuance, more purchase-to-use timing pairs |
| Bounded time window | Fewer tokens, reconnects work | Activity inside the window is linkable |
| Long-lived grant | Operationally simple | Behaves like an account reference with extra steps |
בחר אחד בכוונה ורשום לצידו את התנהגות הכשל. לקוח שמנסה שוב עם הרשאה חדשה אחרי שחלף הזמן צורך יחידה נוספת, וזה גם הפתעה בחיוב וגם אות לפרטיות בעת ובעונה אחת.
כתוב את מדיניות השימוש החוזר והביטול
ביטול הוא המקום שבו תכנונים אנונימיים בדרך כלל שוברים את ההבטחה שלהם. ביטול מינוי והפיכת אסימונים שכבר הונפקו לבטלים הם פעולות שונות, ושער שעושה בשקט חיפוש חשבון כדי להחליט אינו אנונימי יותר בנקודה הזו.
בחר תפוגה, מגבלת הנפקה וסיפור ביטול שמתאימים זה לזה. אחר כך בדוק את הרשומות של השער עצמו אחר שדות שמחזירים את הקישור שהסרת.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
החיפוש הזה מפרט קובצי יומן שמכילים שדות אסימון או חשבון, וזה המקום הראשון שבו תכנון זהיר דולף בפועל. רשומת הפעלה ששומרת את ערך האסימון לצד מזהה חשבון מפרקת את כל המבנה, והיא מגיעה בדרך כלל דרך שינוי ניפוי באגים שאיש לא חזר אליו.
הגדר גם מה השער שומר אחרי שההפעלה מסתיימת. משך, בתים ונקודת קצה שימושיים לתפעול, וכל אחד מהם הוא חלק מהפאזל שצופה היה רוצה. שמור על תקופת שמירה קצרה ועל רשימת שדות קצרה, ואחר כך בדוק את שניהם כששינוי ניפוי באגים מוסיף עמודה. איש לא שם לב לשדה יומן חדש עד שהוא נמצא שם שנה.
נסח את הטענה, ואחר כך את התצפיות שנשארות
כתוב את טענת הפרטיות במשפט אחד עם ההנחות שלה: איזה צד חייב להיות בלתי מסוגל לקשר אילו הקשרים, ומה קורה אם המנפיק והשער משווים הערות. תכנון ששורד את המשפט הזה ניתן לבדיקה; תכנון שמתואר רק כ«ידיעה אפסית» לא.
אחר כך פרט מה נשאר גלוי בלי קשר לכל דבר. כתובות מקור, זמני חיבור, גדלי מנות והעובדה הפשוטה שרכישה התרחשה זמן קצר לפני שהחיבור החדש היחיד הופיע כולם מחוץ לקריפטוגרפיה. לקוח אחד שקונה יחידה אחת ומתחבר פעם אחת ניתן לקישור רק לפי התזמון, ואף תכנון אסימונים לא משנה את זה.
התוצאה הכנה היא קישור צר יותר בין חשבון לשימוש, לא הפעלה בלתי נראית. עדיין שווה לבנות אותה, כל עוד התיעוד אומר זאת והרשומות התפעוליות תואמות את הטענה.