للمكالمة الآمنة أكثر من مسار بيانات. تنسّق الإشارات مَن يتصل وكيف ترتبط نقاط النهاية؛ أما مسار الوسائط فيحمل الصوت والفيديو. حماية أحد المسارين لا تحمي الآخر تلقائيًا، ولا يخفي أيّ منهما وحده جميع أنماط الاتصال.
يوفّر WebRTC آليات أمان مهمة، لكن فحوص الهوية في التطبيق وأدوار الخوادم ووضع التسجيل تظل عوامل تحدد حدود الخصوصية الكاملة.
للإشارات والوسائط وظيفتان مختلفتان
| الطبقة | الغرض المعتاد | السؤال الأمني |
|---|---|---|
| الإشارات | الدعوات وأوصاف الجلسات وخيارات الاتصال المرشّحة | مَن يستطيع قراءة معلومات الإعداد أو تعديلها، وكيف تُوثَّق هوية الطرف المقصود؟ |
| الوسائط | الصوت والفيديو والتدفقات الآنية ذات الصلة | أين ينتهي التشفير، وأي نقاط نهاية تستطيع الوصول إلى الوسائط؟ |
| السجلات التشغيلية | التوجيه وتوقيت الاتصال وحالة التسليم | ما البيانات الوصفية التي يمكن للخدمة أو الشبكة رصدها؟ |
| التسجيل | إنشاء نسخة يُحتفظ بها | مَن يتلقى النص الصريح أو مفاتيح تسجيل قابلة للاستخدام، وأين تُخزَّن النسخة؟ |
يمكن لبروتوكول المراسلة حمل إشارات مشفّرة، لكن WebRTC لا يفرض عمومًا تنسيق مغلّف خاصًا بتطبيق مراسلة بعينه. وتوجد تصاميم أخرى موثَّقة الهوية ممكنة.
ما الذي يوفّره DTLS-SRTP
تُلزم بنية أمان WebRTC، RFC 8827 بحماية قنوات الوسائط، وتصف إنشاء مفاتيح DTLS-SRTP. بصورة مبسطة، يساعد DTLS في إنشاء السياق التشفيري، ويحمي SRTP حزم الوسائط الآنية.
تكتسب نقطتا نهاية هذه الحماية أهمية كبيرة. فالاتصال المشفّر المباشر بين المشاركين يختلف عن اتصال ينتهي عند خادم لمعالجة الوسائط. تضيف بعض الأنظمة متعددة الأطراف طبقة مستقلة من طرف إلى طرف فوق تشفير النقل المتجه إلى الخادم. وكلمة «WebRTC» وحدها لا تخبرك بالبنية التي يستخدمها المنتج.
لماذا تهم مصادقة الإشارات
قد يتضمن إعداد المكالمة معلومات تُستخدم لربط اتصال الوسائط بالطرف المقصود. إذا استطاع مهاجم استبدال هذه المعلومات من دون كشفه، فقد ينشئ التشفير اتصالًا محميًا بنقطة نهاية غير صحيحة.
يناقش RFC 8827 هذه العلاقة بين الإشارات والهويات وبصمات DTLS. يحمي HTTPS اتصالًا بخدمة الإشارات، لكنه لا يلغي بمفرده ضرورة أخذ خدمة خبيثة أو مخترقة في الحسبان. ويمكن للإشارات الموثَّقة من طرف إلى طرف، أو لآلية مستقلة مناسبة للتحقق من الطرف الآخر، أن تقوّي هذه الحدود.
سرية الإشارات هدف مرتبط لكنه مختلف: فهي تحدّ ممن يستطيع قراءة تفاصيل الإعداد. ينبغي للتصميم شرح السرية والمصادقة معًا بدل اعتبار كتلة بيانات مشفّرة دليلًا كافيًا على كلتيهما.
الإشارات المشفّرة لا تجعل المكالمة غير مرئية
قد يظل وسيط الترحيل يعرف الحسابات أو الأجهزة التي يوجّه البيانات بينها. وقد يرى مراقبو الشبكة توقيت الاتصال وحجم الحركة وعناوين الخوادم. كما يمكن للأطراف أو بنية الترحيل معرفة معلومات الشبكة، بحسب تصميم الاتصال.
بناءً على ذلك، لا يثبت تشفير دعوة المكالمة أن الخدمة لا تستطيع استنتاج وقوع مكالمة، أو رسم العلاقات، أو الاحتفاظ بسجلات مرتبطة بالمكالمات. إخفاء المحتوى وإخفاء أنماط حركة البيانات مسألتان منفصلتان.
الحدود التي نشرتها Livara
تصف صفحة الأمان في Livara المكالمات المباشرة والجماعية بأنها مشفّرة من طرف إلى طرف، لكنها تضع استثناءً صريحًا للتسجيل الاختياري على الخادم: أثناء تفعيل حالة REC المرئية، تستخدم المكالمة تشفير النقل بدلًا من E2EE.
كما يرفض نموذج التهديد ادعاءات إخفاء هوية البيانات الوصفية والحماية من جهاز مخترق. هذه تصريحات عن المنتج، وليست تحققًا مستقلًا من كل مسار للمكالمات. لا يدّعي هذا الدليل حدًا غير موثّق لعدد المشاركين، أو تنسيقًا غير متحقق منه للإشارات، أو تنفيذًا غير متحقق منه لوسائط ما بعد الكم.
وعلى وجه الخصوص، فإن تبادل مفاتيح مقاومًا للكم في تطبيق المراسلة لا يرقّي تلقائيًا مصافحة وسائط WebRTC المنفصلة. يجب تقييم الخوارزميات وربط المفاتيح في مسار الوسائط على نحو مستقل.
قبل مكالمة حساسة
- تأكد من المشاركين وراجع تغييرات الهوية غير المتوقعة.
- تحقق مما إذا كان التسجيل مفعّلًا، وما الذي يقول التطبيق إن ذلك يغيّره.
- افهم ما إذا كانت الخدمة تعالج الوسائط أم تكتفي بتمرير الحزم المحمية.
- ضع في الحسبان الأجهزة والغرف المحيطة بالمشاركين: يمكن للبرمجيات الخبيثة أو التقاط الشاشة أو مستمع قريب كشف المحتوى بعد فك التشفير.
- اطلب أدلة على البنية والاختبارات للوضع المحدد الذي تستخدمه، بدل الاعتماد على شارة عامة تقول «مكالمات مشفّرة».
الادعاء الأمني المفيد يحدد، كلًّا على حدة، مَن يستطيع الوصول إلى الإشارات والوسائط والبيانات الوصفية والتسجيلات.
