לשיחה מאובטחת יש יותר מנתיב נתונים אחד. האיתות מתאם מי מתקשר ואיך נקודות הקצה מתחברות; נתיב המדיה נושא את האודיו והווידאו. הגנה על נתיב אחד אינה מגינה אוטומטית על האחר, ואף אחד מהם לבדו אינו מסתיר את כל דפוסי התקשורת.
WebRTC מספק מנגנוני אבטחה חשובים, אבל בדיקות הזהות של היישום, תפקידי השרתים ומצב ההקלטה עדיין קובעים את גבול הפרטיות המלא.
איתות ומדיה ממלאים תפקידים שונים
| שכבה | מטרה טיפוסית | שאלת אבטחה |
|---|---|---|
| איתות | הזמנות, תיאורי הפעלות ומועמדים לחיבור | מי יכול לקרוא או לשנות את מידע הקמת החיבור, וכיצד מאומתת זהות בן השיחה המיועד? |
| מדיה | אודיו, וידאו וזרמים קשורים בזמן אמת | היכן מסתיימת ההצפנה, ואילו נקודות קצה יכולות לגשת למדיה? |
| רשומות תפעוליות | ניתוב, תזמון חיבורים ומצב מסירה | באילו מטא־נתונים השירות או הרשת יכולים לצפות? |
| הקלטה | יצירת עותק שנשמר | מי מקבל טקסט גלוי או מפתחות הקלטה שמישים, והיכן העותק מאוחסן? |
פרוטוקול מסרים יכול לשאת איתות מוצפן, אבל WebRTC אינו מחייב באופן אוניברסלי את פורמט המעטפת של יישום מסרים מסוים. אפשריים גם תכנונים מאומתים אחרים.
מה DTLS-SRTP מספק
ארכיטקטורת האבטחה של WebRTC, RFC 8827, מחייבת הגנה על ערוצי המדיה ומתארת הקמת מפתחות באמצעות DTLS-SRTP. במונחים פשוטים, DTLS מסייע בהקמת ההקשר הקריפטוגרפי, ו־SRTP מגן על חבילות המדיה בזמן אמת.
נקודות הקצה של ההגנה הזאת חשובות. חיבור מוצפן ישיר בין משתתפים שונה מחיבור שמסתיים בשרת לעיבוד מדיה. חלק מהמערכות מרובות המשתתפים מוסיפות שכבת מקצה לקצה נפרדת מעל הצפנת התעבורה מול השרת. המונח ״WebRTC״ לבדו אינו אומר באיזו ארכיטקטורה מוצר משתמש.
מדוע אימות האיתות חשוב
הקמת שיחה יכולה לכלול מידע המשמש לקשירת חיבור המדיה לצד המיועד. אם תוקף יכול להחליף את המידע הזה בלי להתגלות, ההצפנה עלולה להקים חיבור מוגן לנקודת הקצה הלא נכונה.
RFC 8827 דן בקשר הזה בין איתות, זהויות וטביעות אצבע של DTLS. HTTPS מגן על החיבור לשירות האיתות; הוא אינו מבטל כשלעצמו את הצורך להביא בחשבון שירות זדוני או שירות שנפרץ. איתות עם אימות מקצה לקצה או מנגנון מתאים ועצמאי לאימות בן השיחה יכולים לחזק את הגבול הזה.
סודיות האיתות היא מטרה קשורה אך שונה: היא מגבילה מי יכול לקרוא את פרטי הקמת החיבור. התכנון צריך להסביר הן את הסודיות והן את האימות, ולא להתייחס לגוש נתונים מוצפן כאל ראיה מספקת לשניהם.
איתות מוצפן אינו הופך שיחה לבלתי נראית
הממסר עדיין עשוי לדעת בין אילו חשבונות או מכשירים הוא מנתב. צופים ברשת עשויים לראות את תזמון החיבורים, נפח התעבורה וכתובות השרתים. גם בני השיחה או תשתית הממסר יכולים ללמוד מידע רשת, בהתאם לתכנון החיבור.
לכן הצפנת הזמנה לשיחה אינה מוכיחה שהשירות אינו יכול להסיק שמתקיימת שיחה, למפות קשרים או לשמור רשומות הקשורות לשיחה. הסתרת התוכן והסתרת דפוסי התעבורה הן בעיות נפרדות.
גבול ההגנה ש־Livara מפרסמת
עמוד האבטחה של Livara מתאר שיחות ישירות וקבוצתיות כמוצפנות מקצה לקצה, אך מציין חריג מפורש להקלטה אופציונלית בשרת: כל עוד חיווי REC הגלוי פעיל, השיחה משתמשת בהצפנת תעבורה ולא ב־E2EE.
מודל האיומים שלה גם דוחה טענות לאנונימיות של מטא־נתונים ולהגנה מפני מכשיר שנפרץ. אלה הצהרות על המוצר, לא אימות עצמאי של כל נתיב שיחה. מדריך זה אינו טוען למגבלת משתתפים, לפורמט איתות או למימוש מדיה פוסט־קוונטי שלא אומתו.
בפרט, החלפת מפתחות פוסט־קוונטית ביישום המסרים אינה משדרגת אוטומטית לחיצת יד נפרדת של מדיית WebRTC. יש להעריך בנפרד את האלגוריתמים ואת קשירת המפתחות בנתיב המדיה.
לפני שיחה רגישה
- ודאו את זהות המשתתפים ובדקו שינויי זהות בלתי צפויים.
- בדקו אם ההקלטה מופעלת ומה היישום אומר שמשתנה בעקבות זאת.
- הבינו אם השירות מעבד מדיה או רק מעביר חבילות מוגנות.
- הביאו בחשבון את המכשירים והחדרים שסביב המשתתפים: נוזקה, לכידת מסך או אדם שמאזין בקרבת מקום יכולים לחשוף תוכן לאחר הפענוח.
- בקשו פרטי ארכיטקטורה וראיות בדיקה למצב המדויק שבו אתם משתמשים, במקום להסתמך על תג כללי של ״שיחות מוצפנות״.
טענת אבטחה מועילה מזהה בנפרד מי יכול לגשת לאיתות, למדיה, למטא־נתונים ולהקלטות.
