مشاركة مفتاح TLS مقابل شهادة العميل: أيّهما يسجّل الدخول؟
افصل اتفاق المفتاح عن مصادقة العميل وهوية التطبيق، واقرأ رسائل المصافحة التي تُظهر أيّها استخدمه الاتصال فعلاً.
حمل قيمة تبادل مفاتيح عامة داخل المصافحة ليس الحدث نفسه الذي يمثّله تسجيل دخول العميل. أحد الحدثين ينشئ حالة تشفيرية للاتصال؛ والآخر يبيّن من هو العميل، ولا يحدث إلا حين يطلبه الخادم ويدعمه التبادل. والتعامل مع الأول على أنه الثاني يقود إلى استنتاجات خاطئة حول ما يخفيه VPN وما لا يخفيه. اقرأ الرسائل، ثم قرّر أيّاً من الخصائص الأربع لاحظته فعلاً.
كائنان يبدوان متشابهين في التقاط الشبكة
يمكن لعميل TLS 1.3 أن يسهم بمادة تبادل المفاتيح في أول رحلة له دون تقديم أي شهادة. هذا الإسهام علني بالتصميم، لأن الخادم يحتاجه لاشتقاق السر المشترك. وشهادة العميل رسالة أخرى، لا تُرسل إلا بعد أن يطلب الخادم واحدة. وهي تحمل هوية يتحقق منها الخادم بعد ذلك، والمصادقة المتبادلة قرار يتخذه الخادم لا خاصية تستلزمها حزمة التشفير. وهوية التطبيق أمر ثالث تماماً: نموذج دخول، أو رمز حامل، أو كوكي. لا شيء من ذلك يظهر في المصافحة، وكلّه يصمد أمام تغيّر مسار الشبكة.
| Object in play | What it establishes |
|---|---|
| Key-exchange share | Cryptographic state for this connection |
| Server certificate | Which server the client reached |
| Client certificate | Client authentication, when requested |
| Application session | Account identity inside the application |
الصفوف الأربعة مستقلة. يمكن للاتصال أن يضم الصفين الأول والثاني، ويتجاوز الصف الثالث، ويظل يحمل الصف الرابع في ترويسة كوكي.
قرّر ما يمكن لمصافحة ملتقطة أن تثبته
من المصافحة وحدها يتعلم المراقب النسخة المتفاوض عليها، وحزمة التشفير، وشهادة الخادم، وقيم تبادل المفاتيح العامة. وهذا يكفي لأخذ بصمة تنفيذ العميل ولمعرفة الخادم الذي جرى الاتصال به. وما لا تقدمه هو الحالة الخاصة اللازمة لفك تشفير الاتصال، فسريّتها تقوم على التبادل المؤقت لا على المشاركة العلنية. ولا تقدم أيضاً هوية حساب، وهي لم تكن في المصافحة من الأصل.
لذا فالاستنتاج الأمين ضيّق: لم تُقدَّم أي شهادة عميل في هذا التبادل. والأمر ليس أن العميل لم يرسل شيئاً قابلاً للربط، وبالتأكيد ليس أن الجلسة لم تحمل أي معرّف.
اقرأ الرسائل بدل اسم حزمة التشفير
اسأل الخادم عمّا يطلبه، بدل أن تستنتج من حزمة التشفير. فمصافحة TLS 1.3 التي تضم طلب شهادة ظاهرة في النص المسجّل، وغيابها ظاهر بالقدر نفسه.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'ثم أعد التجربة مع إعداد شهادة عميل، وقارن. يجب أن يُظهر التشغيل الثاني إرسال الشهادة وقبولها؛ ويجب ألا يُظهر الأول شيئاً، وهذا هو الفرق الملموس الذي يدور عليه الجدل.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quietإن كنت تحتاج حالة التصفح العادية فقط، فمخرجات العميل المطوّلة تكفي لرؤية نسخة البروتوكول ونتيجة التحقق وما إذا عُرضت شهادة عميل. والخادم الذي لا يرسل طلب شهادة أبداً لا يمكن أن يكون قد تلقى واحدة.
أين يغيّر استئناف الجلسة الجواب
يستخدم استئناف TLS 1.3 تذاكر مرتبطة بحالة سرية، فيمكن لاتصال لاحق أن يكتمل دون تبادل شهادات كامل. وهذا يقلّل ما يراه المراقب ويغيّر ما يثبته النص المسجّل. وهو لا يخلق هوية حيث لم تكن هناك هوية. والجلسة المستأنفة تظل تابعة للجلسة التطبيقية نفسها، وأي كوكي أو رمز في تلك الجلسة يبقى المعرّف المهم.
لهذا السبب تفوت مراجعة الخصوصية التي تتوقف عند "لا شهادة عميل" الجزء المثير. والسؤال الذي يجب طرحه هو أي طرف يحمل معرّفاً مستقراً، لا أي رسالة غابت من مصافحة واحدة.
سجّل أربع خصائص، لا حكماً واحداً
اكتب اتفاق المفتاح، والتحقق من الخادم، ومصادقة العميل، وهوية التطبيق في أربعة أسطر منفصلة، مع الدليل على كل منها. هذا الجرد يصمد أمام تغيّر نسخة البروتوكول، ويجعل الحجة حول الخصوصية قابلة للتحقق من شخص آخر. ثم أضف ما يقدمه مسار الشبكة. فـ VPN يغيّر عنوان المصدر الذي تراه الخدمة؛ وهو لا يزيل تسجيل دخول ولا كوكي ولا بصمة جهاز يملكها التطبيق بالفعل.
سجّل النسخة المتفاوض عليها للاتصال ونتيجة طلب الشهادة معاً، لأن هذين الزوجين ما يحتاجه المراجع لإعادة إنتاج استنتاجك دون التقاط خاص به.