این دیدگاه را به اشتراک بگذارید

تماس امن بیش از یک مسیر داده دارد. سیگنال‌دهی هماهنگ می‌کند چه کسی تماس می‌گیرد و نقاط پایانی چگونه متصل می‌شوند؛ مسیر رسانه صدا و تصویر را حمل می‌کند. حفاظت از یک مسیر، مسیر دیگر را خودکار محافظت نمی‌کند و هیچ‌یک به‌تنهایی تمام الگوهای ارتباطی را پنهان نمی‌کند.

WebRTC سازوکارهای امنیتی مهمی فراهم می‌کند، اما بررسی هویت در برنامه، نقش سرورها و حالت ضبط همچنان مرز کامل حریم خصوصی را تعیین می‌کنند.

سیگنال‌دهی و رسانه کارهای متفاوتی انجام می‌دهند

لایه هدف معمول پرسش امنیتی
سیگنال‌دهی دعوت‌ها، توصیف نشست و گزینه‌های اتصال چه کسی اطلاعات راه‌اندازی را می‌خواند یا تغییر می‌دهد و هویت طرف موردنظر چگونه احراز می‌شود؟
رسانه صدا، تصویر و جریان‌های بلادرنگ مرتبط رمزنگاری کجا خاتمه می‌یابد و کدام نقاط پایانی به رسانه دسترسی دارند؟
سوابق عملیاتی مسیریابی، زمان اتصال و وضعیت تحویل سرویس یا شبکه چه فراداده‌ای را می‌تواند مشاهده کند؟
ضبط تولید نسخه‌ای که نگهداری می‌شود چه کسی متن آشکار یا کلیدهای قابل‌استفادهٔ ضبط را دریافت می‌کند و نسخه کجا ذخیره می‌شود؟

یک پروتکل پیام‌رسانی می‌تواند سیگنال‌دهی رمز‌شده را حمل کند، اما WebRTC به‌طور عمومی قالب پوششیِ یک پیام‌رسان خاص را الزام نمی‌کند. طراحی‌های احراز‌شدهٔ دیگر نیز ممکن‌اند.

DTLS-SRTP چه چیزی فراهم می‌کند

معماری امنیتی WebRTC، یعنی RFC 8827، حفاظت از کانال‌های رسانه را الزامی می‌کند و برقراری کلید DTLS-SRTP را توضیح می‌دهد. به زبان ساده، DTLS به ایجاد زمینهٔ رمزنگاری کمک می‌کند و SRTP از بسته‌های رسانهٔ بلادرنگ محافظت می‌کند.

نقاط انتهایی این حفاظت اهمیت دارند. اتصال رمز‌شدهٔ مستقیم میان شرکت‌کنندگان با اتصالی که در سرور پردازش رسانه خاتمه می‌یابد متفاوت است. برخی سیستم‌های چندنفره، یک لایهٔ سرتاسری جداگانه بالای رمزنگاری انتقالِ رو به سرور اضافه می‌کنند. واژهٔ «WebRTC» به‌تنهایی نمی‌گوید محصول از کدام معماری استفاده می‌کند.

چرا احراز اصالت سیگنال‌دهی مهم است

راه‌اندازی تماس می‌تواند اطلاعاتی داشته باشد که برای پیوند دادن اتصال رسانه به طرف موردنظر استفاده می‌شود. اگر مهاجم بتواند آن اطلاعات را بدون شناسایی جایگزین کند، ممکن است رمزنگاری اتصالی حفاظت‌شده به نقطهٔ پایانیِ اشتباه برقرار کند.

RFC 8827 این رابطهٔ میان سیگنال‌دهی، هویت‌ها و اثرانگشت‌های DTLS را بررسی می‌کند. HTTPS از اتصال به سرویس سیگنال‌دهی محافظت می‌کند؛ اما به‌خودی‌خود لزوم درنظرگرفتن سرویس مخرب یا نفوذشده را از بین نمی‌برد. سیگنال‌دهی با احراز اصالت سرتاسری یا سازوکار مناسب و مستقلِ تأیید طرف مقابل می‌تواند این مرز را تقویت کند.

محرمانگی سیگنال‌دهی هدفی مرتبط اما متفاوت است: اینکه چه کسی می‌تواند جزئیات راه‌اندازی را بخواند محدود می‌کند. طراحی باید هم محرمانگی و هم احراز اصالت را توضیح دهد، نه اینکه یک تودهٔ دادهٔ رمز‌شده را مدرک کافی برای هر دو بداند.

سیگنال‌دهی رمز‌شده تماس را نامرئی نمی‌کند

رله ممکن است همچنان بداند میان کدام حساب‌ها یا دستگاه‌ها مسیریابی می‌کند. ناظران شبکه ممکن است زمان اتصال، حجم ترافیک و آدرس سرورها را ببینند. بسته به طراحی اتصال، طرف‌های تماس یا زیرساخت رله نیز می‌توانند اطلاعات شبکه را به دست آورند.

بنابراین، رمزکردن دعوت تماس ثابت نمی‌کند که سرویس نمی‌تواند وقوع تماس را استنباط کند، روابط را ترسیم کند یا سوابق مرتبط با تماس را نگه دارد. پنهان‌کردن محتوا و پنهان‌کردن الگوهای ترافیک دو مسئلهٔ جداگانه‌اند.

مرزی که لیوارا منتشر کرده است

صفحهٔ امنیت لیوارا، تماس‌های مستقیم و گروهی را دارای رمزنگاری سرتاسری توصیف می‌کند، اما برای ضبط اختیاری روی سرور استثنایی صریح قائل است: وقتی وضعیت قابل‌مشاهدهٔ REC فعال است، تماس به‌جای E2EE از رمزنگاری انتقال استفاده می‌کند.

مدل تهدید آن نیز ادعای ناشناس‌بودن فراداده و حفاظت در برابر دستگاه نفوذشده را رد می‌کند. این‌ها اظهارات محصول هستند، نه تأیید مستقل تک‌تک مسیرهای تماس. این راهنما هیچ سقف تأییدنشده‌ای برای تعداد شرکت‌کنندگان، قالب سیگنال‌دهی یا پیاده‌سازی رسانهٔ پساکوانتومی ادعا نمی‌کند.

به‌ویژه، تبادل کلید پساکوانتومیِ پیام‌رسان، دست‌دهی جداگانهٔ رسانهٔ WebRTC را خودکار ارتقا نمی‌دهد. الگوریتم‌ها و پیوند کلید در مسیر رسانه باید مستقل ارزیابی شوند.

پیش از یک تماس حساس

  • شرکت‌کنندگان را تأیید و تغییرات غیرمنتظرهٔ هویت را بررسی کنید.
  • بررسی کنید ضبط فعال است یا نه و برنامه می‌گوید این کار چه چیزی را تغییر می‌دهد.
  • بفهمید سرویس رسانه را پردازش می‌کند یا فقط بسته‌های حفاظت‌شده را عبور می‌دهد.
  • دستگاه‌ها و فضای پیرامون شرکت‌کنندگان را در نظر بگیرید: بدافزار، ثبت صفحه یا شنونده‌ای نزدیک می‌تواند محتوا را پس از رمزگشایی افشا کند.
  • به‌جای اتکا به نشان کلی «تماس‌های رمز‌شده»، شواهد معماری و آزمون را برای همان حالت دقیقی که استفاده می‌کنید بخواهید.

ادعای امنیتیِ مفید، جداگانه مشخص می‌کند چه کسی به سیگنال‌دهی، رسانه، فراداده و ضبط‌ها دسترسی دارد.

اعتبارسنجی معماری
ادامهٔ این موضوعتماس، همگام‌سازی و پایداری ↗حریم خصوصی دیجیتال ↗
پایان مقالهادامهٔ مطالعه ↗