הצפנה מקצה לקצה היא שכבה נוספת, לא רשות להתעלם מאזהרות TLS או לתת אמון בקוד ששונה.
TLS והצפנה מקצה לקצה יוצרים שני גבולות שונים. הגבולות האלה חשובים גם בהערכת VPN ופרוקסי. TLS מגן בדרך כלל על החיבור בין המכשיר שלכם לשירות; הצפנה מקצה לקצה המיושמת נכון וכוללת אימות מגינה על תוכן השיחה עד למכשיר הנמען. קריאת שכבת TLS אינה בהכרח קריאה של התוכן המוצפן מקצה לקצה, אך אין להסיק מכך שאבטחת TLS כבר אינה חשובה.
אם גורם מתווך יכול לסיים אצלו את החיבור המאובטח, הוא עשוי לא רק לצפות בנתונים המועברים אלא גם לשנות תגובות או את קוד יישום האינטרנט. לכן הביטוי ״עקיפת TLS באמצעות LVR1״ אינו תיאור מתאים לאבטחת יישום מסרים.
כיצד תעודת שורש מאפשרת בדיקה?
בחיבור HTTPS, המכשיר בודק את שרשרת התעודות של השרת ואת שם המארח. אם המתווך מציג תעודה שהיישום מחשיב לתקפה, הוא עשוי ליצור שני חיבורים נפרדים: אחד עם המשתמש ואחד עם השרת האמיתי. במקרה כזה המתווך הוא קצה של אחד מחיבורי TLS, ולא מאזין ששבר את ההצפנה רק באמצעות התבוננות במנות.
התקנת תעודה שרירותית לבדה אינה מספיקה; היישום צריך לתת בה אמון, וגם בדיקות החיבור צריכות לעבור בהצלחה. תיעוד הגדרת אבטחת הרשת של Android מסביר שמדיניות האמון עשויה להיות שונה בכל יישום. יישומים המכוונים ל־Android 7.0 ומעלה אינם נותנים כברירת מחדל אמון בתעודות שהמשתמש הוסיף, אלא אם הוגדרו אחרת.
זהו מנגנון טכני כללי. אין להסיק ממנו ללא ראיות מסקנות על מפעיל, מדינה או אירוע מסוימים. שיבוש או סינון לבדם אינם הוכחה לבדיקה מוצלחת של TLS.
אם TLS נפתח, מה ניתן לראות?
| סוג הנתונים או המצב | תוצאה אפשרית של בדיקת TLS |
|---|---|
| תוכן המוגן רק באמצעות HTTPS | המתווך המהימן עשוי לראות את הטקסט |
| הודעה שכבר הוצפנה במפתח התקף של הנמען | המתווך נתקל בדרך כלל בטקסט מוצפן, לא בטקסט ההודעה |
| נתוני ניתוב, הפעלה או בקשות נלוות | מידת החשיפה תלויה בפורמט ובתכנון השירות |
| קוד גרסת הדפדפן המגיע באותו נתיב | שינוי הקוד עלול לאיים על אבטחת נקודת הקצה |
| השירות אינו זמין או שהתעבורה נחסמת | הצפנה לבדה אינה יוצרת חיבור |
הגנת התוכן של E2EE תלויה גם באותנטיות של מפתח הנמען ובשלמות התוכנה בשני הצדדים. אם תוקף מחליף את המפתח הראשוני או משנה את היישום הרואה את ההודעה לפני הצפנתה, עצם קיומם של AES או ML-KEM אינו מספיק.
מדוע גרסת הדפדפן זקוקה ל־TLS תקין?
יישום אינטרנט מקבל בדרך כלל קוד להרצה מהשרת. אם הקוד זדוני, הוא יכול לגשת לתוכן לפני ההצפנה או לאחר הפענוח. אי אפשר להעריך הצפנה מקצה לקצה בנפרד מהאופן שבו הקוד נמסר ומורץ.
גם בגרסה המותקנת חשובים אותנטיות החבילה, העדכונים ושלמות מערכת ההפעלה. חתימת החבילה ובדיקת ערך גיבוב מועילות, אך אינן בדיקת אבטחה מלאה של היישום. גם מודל האיומים של Livara מציין שאם תוקף משנה הן את הקובץ והן את ערך הגיבוב המוצג, התאמת ערכי הגיבוב לבדה אינה מוכיחה אותנטיות.
מה Livara טוענת?
על פי תיעוד האבטחה של Livara, הודעות ישירות משתמשות ב־LVR1 וקבוצות פרטיות תואמות משתמשות ב־LGS1. התיעוד מתאר את השילוב של P-256 ו־ML-KEM-768 ואת הצפנת תוכן ההודעות. אלה טענות של המוצר, לא תוצאות ביקורת עצמאית במאמר זה.
אותו עמוד מציין גם שמטא־נתונים של ניתוב נשמרים ושערוצי פרסום הם ציבוריים. לכן המסקנה הנכונה אינה ש״כל המידע מוסתר״ או ש״אין צורך בשום אמון ברשת״. המסקנה היא שיש לבחון את ההגנה על תוכן פרטי בנפרד מהחיבור, ממסירת המפתחות, מקוד היישום ומהמטא־נתונים.
מה עושים כשמופיעה אזהרת תעודה?
- אל תתעלמו מאזהרת הדפדפן או היישום כדי להמשיך בשיחה רגישה.
- בדקו את התאריך במכשיר ואת הכתובת המדויקת של השירות; לא כל שגיאת תעודה היא בהכרח מתקפה.
- אם זהו מכשיר ארגוני, שאלו את הגורם המוסמך על מדיניות הניהול ועל התעודות המותקנות; אל תשנו הגדרות מנוהלות על דעת עצמכם.
- אל תתקינו תעודה או פרופיל רק משום שהודעה לא מוכרת ביקשה זאת.
- בשיחות רגישות, השוו עם האדם שמולכם את טביעת האצבע של המפתח דרך נתיב עצמאי; השוואת מפתחות אינה תחליף לטיפול באזהרת TLS.
שאלות נפוצות
האם VPN פותר את כל הבעיות האלה?
לא. VPN יכול לשנות את הנתיב שבו ניתן לצפות בתעבורה, אך אינו מתקן אוטומטית מכשיר נגוע, תעודה זדונית שניתנה בה אמון או קוד אינטרנט ששונה.
האם אימות ללא שליחת סיסמה מספיק?
לא. לפרוטוקול האימות, לניהול ההפעלה ולהצפנת ההודעות תפקידים שונים. דף כניסה מזויף או קוד זדוני יכולים לקבל את הקלט עצמו של המשתמש עוד לפני הפעלת הפרוטוקול.
עיקרון מעשי: E2EE היא שכבה בעלת ערך; אל תראו בה רשות להתעלם מתעודות, מאותנטיות היישום או מאימות מפתחות.
