הצפנה בצד הלקוח לשיתוף סודות

הצפנה בצד הלקוח מגינה על סוד שמור מפני מפעיל השירות ומפני כל מי שמשיג את מסד הנתונים, ותו לא: JavaScript זדוני, תוסף דפדפן או קישור שדלף עוקפים אותה, כי המפתח עובר בתוך הקישור. היא לא פתרון קסם, ועל ההבטחה האחת שהיא נותנת משלמים במקומות אחרים.

המדריך הזה מסביר מה הצפנה בדפדפן מבטיחה, איפה היא נכשלת בלי שמרגישים, איך היא נראית לעומת המודל של הצפנה בצד השרת, ואיך LinkPilot משלב בין השניים מאז 29 בספטמבר 2026, כשמחולל הקישורים הסודיים החד-פעמיים שלו עבר להצפנה בדפדפן.

נכתב מחדש ב-19 באוקטובר 2026. הגרסה המקורית של המאמר תיארה את המודל של הצפנה בצד השרת ש-LinkPilot השתמש בו אז; הערה שנוספה ב-29 בספטמבר 2026 תיעדה את המעבר. הגרסה הזאת מתארת לאורך כל הדרך את המודל הנוכחי. הניתוח של מה כל מודל מגן עליו ומה לא נשאר כפי שהיה.

על מה הצפנה בצד הלקוח מגינה בפועל?

על הסוד השמור, מפני מפעיל השירות ומפני כל מי שמשיג את מסד הנתונים. בכלי לשיתוף סודות עם הצפנה בצד הלקוח (שנקראת גם הצפנה מקצה לקצה, או E2EE), התהליך הוא:

1. הדפדפן יוצר מפתח סימטרי, בדרך כלל מפתח AES-GCM באורך 256 ביט, דרך Web Crypto API (crypto.subtle.generateKey).
2. הדפדפן מצפין את התוכן במפתח הזה.
3. רק הטקסט המוצפן נשלח לשרת, והשרת שומר אותו תחת מזהה אקראי.
4. המפתח מצורף לקישור השיתוף בחלק שאחרי הסימן # (#…). לפי RFC 3986, סעיף 3.5, דפדפנים אף פעם לא שולחים את החלק הזה בבקשות HTTP, ולכן המפתח לא עובר ברשת אל השרת.
5. הדפדפן של הנמען קורא את החלק שאחרי ה-#, מוריד את הטקסט המוצפן ומפענח אותו מקומית.

השרת רואה רק טקסט מוצפן. מפעיל שקורא את מסד הנתונים של עצמו, גיבוי של מסד הנתונים שדולף, צו שמחייב למסור נתונים שמורים: אף אחד מהם לא חושף את הסוד, בתנאי שכל שאר החוליות בשרשרת מחזיקות.

האנטומיה של קישור סודי עם E2EE

https://example.com/s/x7Kd93hF2a#4fT9wLm2...Qz1
└──────── sent to the server ───┘└ browser only ┘

כל מה שלפני ה-# עובר בבקשה ויכול להופיע ביומנים של השרת ושל שרתי proxy. מה שאחריו מעובד רק בדפדפן של הנמען. התו האחד הזה עושה את כל עבודת האבטחה. זה פתרון אלגנטי, והוא גם השורש של רוב דרכי הכשל שבהמשך.

ממה הצפנה בצד הלקוח לא מגינה?

מ-JavaScript זדוני או פרוץ, מתוספי דפדפן ומקישור שדלף, כי המפתח נמצא בקישור.

• היא לא מגינה מפני JavaScript זדוני. קוד ההצפנה רץ בדפדפן, והדפדפן קיבל את הקוד הזה מהשרת. אם השרת מגיש קוד ששונה, כי המפעיל הפך לזדוני, חויב לעשות זאת או נפרץ, אפשר לקרוא את הסוד לפני ההצפנה או אחרי הפענוח. זו המגבלה הבסיסית של E2EE בדפדפן.
• היא לא מגינה מפני תוספי דפדפן. תוסף עם גישה לדף רואה את הטקסט הגלוי אחרי הפענוח ויכול לקרוא ישירות את החלק של הקישור שאחרי הסימן #.
• היא לא הופכת קישור שדלף לבלתי מזיק. המפתח הוא חלק מהקישור. אם הנמען מדביק את הקישור המלא בצ'אט, מעביר הלאה את האימייל או שסנכרון היסטוריית הדפדפן פועל אצלו, המפתח עובר יחד איתו. קישור E2EE שכתובתו דלפה הוא סוד שאפשר לקרוא במלואו. ההגנה היחידה היא ביטוי סיסמה שנשלח בערוץ אחר, ולכן LinkPilot משלב את ביטוי הסיסמה במפתח במקום לבדוק אותו בנפרד.
• היא לא מאפשרת ביקורת, סריקה או תצוגה מקדימה של התוכן. השרת לא יכול לקרוא את התוכן, ולכן הוא לא יכול לסנן אותו, לסרוק אותו לאיתור נוזקות או להפעיל עליו מניעת זליגת מידע. הבקרות צריכות לפעול במקום זה על הטקסט המוצפן ועל אירועי הגישה.

בעיית הגשת הקוד, בפירוט

הנקודה שכדאי להתעכב עליה: E2EE בדפדפן פירושו לסמוך על השרת, שלכאורה אתם לא סומכים עליו, שיגיש JavaScript תקין בכל טעינה של הדף. אפליקציה מותקנת פעם אחת, חתומה ובעלת גרסה; דף אינטרנט נטען מחדש בכל ביקור. Subresource Integrity וקוד מקור פתוח מצמצמים את הפער, אבל לא סוגרים אותו.

לכן הקריאה הכנה של "אנחנו לא יכולים לקרוא את הסודות שלכם" היא "אנחנו לא יכולים לקרוא את הסודות שלכם באופן פסיבי". המעבר מיכולת פסיבית למתקפה אקטיבית ששולחת קוד ששונה הוא הסלמה אמיתית (מתקפות אקטיביות מסוכנות יותר לתוקף, ממוקדות ועלולות להתגלות), אבל זה לא אותו דבר כמו "בלתי אפשרי". זה נכון לגבי הטענה של LinkPilot בדיוק כמו לגבי הטענה של כל אחד אחר.

החלופה בצד השרת

התכנון הנפוץ השני, וזה ש-LinkPilot השתמש בו עד ספטמבר 2026, מצפין את הנתונים במנוחה בשרת ומגן על ההצגה באמצעות ביטוי סיסמה מגובב:

• TLS בזמן ההעברה; התוכן נשמר בטבלה ייעודית במסד נתונים עם הצפנה במנוחה ברמת הדיסק.
• ביטויי הסיסמה מגובבים בדפדפן לפני השליחה ומושווים לפי ה-hash; ביטוי הסיסמה עצמו אף פעם לא מגיע למסד הנתונים.
• מחיקה הרסנית: בהצגה הראשונה, בפקיעת התוקף או בביטול הקישור, התוכן השמור נדרס, וניסיונות מאוחרים יותר מקבלים HTTP 410.
• ניסיונות ביטוי סיסמה מוגבלים בקצב ונרשמים ביומן.

במודל הזה השרת יכול לקרוא סוד פעיל. זה מה שמאפשר תצוגה מקדימה, סריקה ותכונות שמבינות את התוכן בצד השרת, וזו בדיוק התכונה ש-E2EE מבטל. כלים בקוד פתוח כמו OneTimeSecret עדיין משתמשים בו; המאמר האם OneTimeSecret בטוח? בוחן את ההשלכות.

מה LinkPilot עושה היום

מאז 29 בספטמבר 2026, LinkPilot משתמש בהצפנה בצד הלקוח ושומר על הבקרות בצד השרת שלא צריכות את התוכן. מתוך העמוד ארכיטקטורת האבטחה:

• הצפנה בדפדפן. התוכן מוצפן ב-AES-GCM-256 עם מפתח של 256 ביט שנוצר בדפדפן של השולח. השרת שומר את הטקסט המוצפן ותו לא; המפתח עובר בחלק של קישור השיתוף שאחרי הסימן #.
• ביטוי סיסמה כחלק מהמפתח (Pro). ביטוי הסיסמה עובר מתיחה ב-PBKDF2-SHA256 (210,000 איטרציות) ומשולב עם מפתח הקישור דרך HKDF-SHA256, כך שלא הקישור לבדו ולא ביטוי הסיסמה לבדו מפענחים את הסוד. הניסיונות מוגבלים ל-5 לכל IP בדקה לכל סוד, באמצעות מגביל בזיכרון וחלון נע שמגובה במסד הנתונים.
• מחיקה לאחר קריאה של הטקסט המוצפן. הצפייה נרשמת דרך פונקציה במסד הנתונים, כצעד אחד שאי אפשר לפצל, כך שניסיונות הצגה מקבילים לא יכולים להדליף את הסוד פעמיים; הטקסט המוצפן השמור נדרס ב-[REDACTED], וניסיונות מאוחרים יותר מחזירים HTTP 410.
• ביטול הקישור. אפשר לבטל את הקישור של סוד מלוח הבקרה בכל רגע; סודות שהקישור שלהם בוטל לא מוצגים ומחזירים 410.
• הצגה שעמידה בפני תצוגות מקדימות. בוטים של תצוגה מקדימה של קישורים וסורקי אימייל שולחים בקשות GET, והן מחזירות מטא-נתונים בלבד (סטטוס, והאם נדרש ביטוי סיסמה). צפייה נרשמת רק כשמישהו לוחץ במפורש על הצגה בדפדפן.
• יומן ביקורת (Pro). יצירה, צפייה, ביטוי סיסמה שגוי, מחיקה, פקיעת תוקף וביטול הקישור, כל אחד עם חותמת זמן, המדינה והעיר שה-edge מדווח, מחרוזת הדפדפן ו-hash של הכתובת עם salt יומי. היומן מתעד גישה, אף פעם לא תוכן.
• קבצים. גם קבצים מצורפים מוצפנים בדפדפן, במפתח שנגזר ממפתח הקישור. השם, הגודל והסוג של הקובץ נשארים גלויים ל-LinkPilot כמטא-נתונים.

שלוש מגבלות, בלי ייפוי. סודות שנוצרו לפני 29 בספטמבר 2026 נשמרו כטקסט גלוי עד שתוקפם פג; הם לא נכתבו מחדש. המטא-נתונים של קבצים גלויים, אף שהתוכן שלהם לא. וכל מה שמופיע בסעיף "ממה היא לא מגינה" תקף: JavaScript זדוני, תוספי דפדפן וקישור שדלף לא נפתרים במודל הזה או בכל מודל אחר שמבוסס על דפדפן.

סיכום הפשרות

אין מודל ש"מאובטח יותר" באופן מופשט. כל אחד מגן מפני איומים אחרים במחיר אחר, ושילוב ביניהם מצמצם את מה שמוותרים עליו, אבל לא מבטל אותו.

התאמת המודל לאיום: שלושה תרחישים

1. שליחת סיסמה למסד נתונים לקבלן חיצוני. האיום הוא שהסוד יישאר באימייל או בצ'אט, או יועבר הלאה בטעות. כל מודל מטפל בזה עם תפוגה קצרה ומחיקה לאחר קריאה; מה שמכריע הוא נוחות השימוש והתיעוד. הצפנה בדפדפן עם ביטוי סיסמה שנשלח בערוץ נפרד, ויומן שמראה מתי הקישור נפתח, הם הבחירה המעשית.

2. עיתונאי שמקבל חומר ממקור. מודל האיום כולל מצב שבו מחייבים את מפעיל הפלטפורמה למסור מידע. כאן המפעיל הוא חלק מהאיום, ולכן E2EE הוא המינימום, וכלים ייעודיים כמו SecureDrop, שכל המערכת שלהם תוכננה סביב האיום הזה, הם הבחירה הנכונה. כלי אינטרנט שאפשר לחייב אותו להגיש JavaScript ששונה לא מספיק לבדו.

3. צוות פיתוח שמעביר פרטי התחברות באופן שגרתי. האיום הוא התפזרות: קישורים שנשכחו, ואין תיעוד של מי ראה מה. התכונות החשובות הן היומן, ביטול הקישורים, התפקידים בסביבת העבודה ומדיניות תפוגה. פעם הן חייבו שרת שיכול לקרוא את התוכן; היום כבר לא, כי הן פועלות על טקסט מוצפן ועל אירועי גישה. שיתוף סיסמאות מאובטח לצוותים עוסק בצד המדיניות של התרחיש הזה.

איך בוחרים

בחרו הצפנה בצד הלקוח כש:

• אתם לא סומכים על המפעיל, כולל על עצמכם כשאתם מריצים על תשתית ענן שאי אפשר לאמת עד הסוף.
• כללים רגולטוריים או חוזיים דורשים שלספק לא תהיה יכולת טכנית לקרוא את התוכן.
• אתם מתכוונים לשלוח את ביטוי הסיסמה בערוץ שני ולשמור על תפוגה קצרה, כי אחרת קישור שדלף הוא הסוד כולו.

בחרו הצפנה בצד השרת כש:

• אתם צריכים שהשרת יבדוק את התוכן: סריקה לאיתור נוזקות, מניעת זליגת מידע, סינון תוכן.
• אתם מארחים בעצמכם כלי שיש לו מטרה אחת, והמפעיל הוא אתם.

חפשו את שניהם כש:

• אתם רוצים להוציא את המפעיל משרשרת האמון ועדיין צריכים יומן, ביטול קישורים, תפקידים בצוות והצגה שתצוגה מקדימה של קישור לא יכולה להפעיל. שאלו את הספק אילו בקרות פועלות על הטקסט המוצפן ואילו צריכות בשקט טקסט גלוי.

האם כלי הצפנה אונליין הוא הבחירה הנכונה?

מי שמחפש כלי הצפנה אונליין רוצה בדרך כלל אחד משני דברים: להפוך קטע טקסט לטקסט מוצפן שאפשר להדביק בכל מקום, או להעביר הודעה רגישה לאדם אחד בבטחה. הראשון הוא כלי. השני הוא תהליך, והכלי לבדו לא משלים אותו.

דף שמדביקים בו טקסט להצפנה מצפין אותו בדפדפן, אם הוא בנוי היטב, ואת זה אפשר לבדוק בשלבים שבסעיף על בדיקת טענות, בהמשך. מה שהוא משאיר לכם הוא כל מה שמסביב לטקסט המוצפן: לבחור ביטוי סיסמה חזק, לשלוח את ביטוי הסיסמה בערוץ נפרד, למחוק את הטקסט המוצפן מכל מקום שהדבקתם אותו, ולברר אם הנמען הצליח לפענח אותו. קידוד הוא לא הצפנה, ולכן כלי Base64 לא מגן על שום דבר, וביטוי סיסמה חלש הוא הדרך הרגילה שבה הצפנה בדפדפן נכשלת בפועל.

קישור סודי חד-פעמי מבצע את אותה הצפנה בדפדפן ומטפל בשאר התהליך: המפתח עובר בחלק של הקישור שאחרי הסימן #, העותק השמור מושמד בפתיחה הראשונה, תוקף הקישור פג אם אף אחד לא פותח אותו, והשולח יכול לראות שהסוד הוצג. להודעה לאדם, זו ההתאמה הטובה יותר. לטקסט מוצפן שאתם צריכים לשמור בעצמכם, או להדביק במערכת שבשליטתכם, כלי מקומי כמו age או GPG עדיף על כל דף אינטרנט, כי המפתח לא נוגע בדפדפן בכלל.

מתי לא להשתמש באף אחד מהם

יש סודות שלא צריכים לעבור בשום קישור שיתוף. פרטי התחברות של root לטווח ארוך, מפתחות חתימה של סביבת הייצור וייצוא של נתונים בכמות גדולה שייכים למנהל סודות או ל-KMS עם בקרת גישה, לא ל-URL. ואם הנמען צריך את הערך שוב ושוב, פריט בכספת של מנהל סיסמאות עדיף על שליחת קישורים חוזרת; מסירה חד-פעמית נועדה להעברה, לא לאחסון. המאמר קישורים סודיים לעומת מנהלי סיסמאות משרטט את הגבול הזה.

איך בודקים טענה

אל תבחרו כלי לפי מי שמבטיח יותר. בחרו לפי מה שאתם מגינים מפניו, ובדקו שמה שכתוב על האריזה תואם לארכיטקטורה שמתחת:

• האם המפתח נמצא בחלק שאחרי הסימן #? בדקו את מבנה הקישור: המפתח צריך להופיע אחרי ה-#.
• האם בקשה פשוטה לקישור מחזירה את הסוד? היא לא אמורה.
• מה ביטוי הסיסמה עושה: חוסם את ההצגה, או מהווה חלק מהמפתח?
• מה נרשם ביומן, והאם המפעיל מציין זאת בכתב?

התשובות של LinkPilot מופיעות בעמוד ארכיטקטורת האבטחה, כולל המגבלות. על העמוד הזה חל אותו מבחן כמו על העמוד של כל אחד אחר.

לקריאה נוספת

• איך עובדים קישורים לסודות חד-פעמיים
• האם OneTimeSecret בטוח?
• LinkPilot לעומת PrivateBin
• קישורים סודיים לעומת מנהלי סיסמאות
• למה כתובות URL מדליפות מידע רגיש
• סורקי קישורים וסודות חד-פעמיים

מקורות

• W3C, Web Cryptography API.
• NIST, SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
• IETF, RFC 3986, section 3.5 Fragment.
• Freedom of the Press Foundation, SecureDrop.