هل يمكن لـ 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/
يسرد ذلك البحث ملفات السجل التي تحتوي حقول رموز أو حسابات، وهو أول موضع يتسرب فيه تصميم حذر على أرض الواقع. فسجل جلسة يخزّن قيمة الرمز بجانب معرّف حساب يهدم البناء كله، وهو يصل عادة عبر تغيير للتنقيح لم يراجعه أحد.
حدّد أيضًا ما تحتفظ به البوابة بعد انتهاء الجلسة. المدة والحجم ونقطة النهاية مفيدة للتشغيل، وكل منها قطعة من الأحجية يود مراقب الحصول عليها. أبقِ مدة الاحتفاظ قصيرة وقائمة الحقول قصيرة، ثم راجع الاثنين عندما يضيف تغيير للتنقيح عمودًا. لا يلاحظ أحد حقل سجل جديدًا قبل أن يمضي عليه عام.
اذكر الادعاء، ثم الملاحظات التي تبقى
اكتب ادعاء الخصوصية في جملة واحدة مع افتراضاته: أي طرف يجب أن يكون عاجزًا عن ربط أي سياقات، وماذا يحدث إذا قارن المُصدِر والبوابة ملاحظاتهما. التصميم الذي ينجو من تلك الجملة قابل للمراجعة؛ أما الذي يوصف بأنه «معرفة صفرية» فقط فليس كذلك.
ثم اسرد ما يبقى ظاهرًا مهما كان. عناوين المصدر وأوقات الاتصال وأحجام الحزم ومجرد أن عملية شراء حدثت قبل ظهور الاتصال الجديد الوحيد بفترة قصيرة، كلها خارج التشفير. عميل واحد يشتري وحدة واحدة ويتصل مرة واحدة يمكن ربطه بالتوقيت وحده، ولا يغيّر أي تصميم رموز ذلك.
النتيجة الصادقة هي ربط أضيق بين الحساب والاستخدام، لا جلسة غير مرئية. وهذا ما يزال يستحق البناء، ما دامت الوثائق تقول ذلك والسجلات التشغيلية تطابق الادعاء.