זה לא נדיר, אך ייתכן שלא נדרש. נראה כי הרבה מפתחים שוכחים שתעבורת HTTPS כבר מוצפנת - רק תסתכל על מספר השאלות לגבי יישום הצפנה בצד הלקוח באתר זה - או מרגיש שאי אפשר לסמוך עליה בגלל בעיות מתוקשרות כמו ה בלגן SSL MitM של לנובו.

עם זאת, רוב האנשים לא הושפעו מכך, ואין כרגע התקפות קיימא במיוחד נגד TLSv1.2, אז זה לא ' לא באמת להוסיף הרבה.

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

בעיקרו של דבר, זה תלוי במה אתה מגן - אם אינך סומך על SSL / TLS, ככל הנראה אינך יכול לסמוך על ההצפנה. גם את הקוד שאתה שולח (במקרה של יישום האינטרנט)!

HTTPS מספק הצפנה רק בזמן שההודעה עוברת ברשת / באינטרנט.

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

כמו כן, אם TLS / SSL יסתיים בהיקפי השירות (למשל במאזן עומסים), ייתכן שהוא לא מוצפן ברשת הפנימית. זו עשויה להיות בעיה בה נדרשת אבטחה גבוהה, למשל בסביבות מוסדרות מסוימות.

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

כפי שאמר @honze, זה נקרא הגנה לעומק וזה נועד להבטיח שגם אם מערכת נפגעת באופן חלקי (למשל, הם מצליחים לבצע התקפה של איש באמצע. כדי להתפשר על SSL / TLS, או לנצל פגיעות בתור ההודעות כדי להגיע לנתונים במנוחה) התוקף לא יכול להגיע לנתונים המוגנים.

ברצוני לשתף את החוויה שלי בשאלת הכותרת. זה לא ממש קשור לשאלה המלאה עצמה, אך זה עונה על השאלה "מדוע מישהו יצפין כפול?"

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

הסכימה הייתה בערך הבאה:

  נותן טיפול 1 \ / ארגון ביטוח 1 ספק שירותי 2 ---- נתב (us) ---- ביטוח ארגון 2 ספק שירותי 3 / \ ארגון מבטח 3  

הייתה לנו ההגנה הבאה:

1. הצפנה מקצה לקצה : המטפל 1 צריך לשלוח מידע על המטופל לארגון המבטח 1. מידע זה רגיש לפרטיות ולכן צריך להיות מוצפן. ברמתנו אין לנו זכות לדעת אילו נתונים נשלחים לארגון המבטח.
2. ספק טיפול - הצפנת נתב: נותן הטיפול שולח לנו מידע כמטא נתונים ל להיות מסוגל להתמודד עם זה. מידע זה צריך להיות מוצפן. בחוזה נכתב כי ההודעות עדיין צריכות להיות מוצפנות גם בתוך הרשת שלנו, כך שרק אחד מהשרתים שלנו יודע אי פעם את מטא הנתונים של המידע שנשלח. מכיוון שיש לנו מספר צינורות (איזוני עומסים, חומת אש וכו '), נדרש הצפנה גם ברמה זו.
3. HTTPS כדי למנוע התקפות MITM: לא רק שהנתונים שלנו היו זקוקים. כדי להיות מוגן, אך גם את מטא הנתונים של HTTP היה צריך להגן, לכן HTTPS.

אני מקווה שזה ישפוך מעט אור מדוע ניתן לדרוש מספר שכבות הצפנה.

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

ההודעות המוצפנות עשויות לטפל בהצפנה מקצה לקצה ו- SSL / TLS מטפל בהצפנה של המטא-נתונים. זהו דפוס שימושי.

HTTPS מוצפן במעבר ומפענח בקצותיו. אז המצב הברור בו אולי תרצו להצפין פעמיים הוא שבו אתם לא רוצים שאחד (או אולי שניהם!) מהקצוות יראה את הטקסט המובהק.

כמה מצבים אני יכול לחשוב על החלק העליון של הראש שלי:

• דוא"ל מוצפן דרך ספקי דואר אלקטרוני. אם אני שולח הודעה מוצפנת באמצעות GPG דרך Gmail אליה אני ניגש דרך חיבור HTTPS, היא מוצפנת פעמיים. מכיוון שאני לא רוצה ש- gmail יקרא את התוכן.

• שירותי גיבוי מוצפנים. אני רוצה להשתמש ב- HTTPS כדי למנוע את גניבת אישורי הכניסה שלי, אבל אני לא רוצה ששירות הגיבוי יראה "בתוך" הגיבויים.

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

שים לב ש- S / MIME מספק "עטיפה משולשת" (סימן / הצפן / סימן): https://tools.ietf.org/html/rfc2634, כך שאם אתה מחשיב חתימה וכן הצפנה אפשרויות רבות יותר עשויות להיות הגיוניות .

רציתי לתת סיבה נוספת: סטנדרטיזציה.

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

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

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

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

אם אינך מתמודד עם סביבה כבדה ברשת. עם נתונים רגישים אז זה מוגזם.

האסטרטגיה שמאחורי שיטה זו מבטיחה שאומתו על המכשירים, הרכיבים (MAC) ו- IP. הצפנת נתונים היא הליך סטנדרטי וכך גם שליחה באמצעות HTTPS. ארגונים מסוימים חורגים מהאבטחה הבסיסית וגם דורשים רשתות דמויי רשת המשתמשות ב- Freenet, I2P, IPsec / VPN או Tor כדי להתחבר. ללא קשר להצפנה, דחיסת הנתונים תפחית את משאבי האחסון והרשת הנדרשים; עם זאת, זה יקזז את הביצועים שלך ל- RAM או לעיבוד. לבסוף, הסיבה שהתחלנו מחדש את החיבור לאחר ניתוק היא שגילינו דרך לחטוף את זרם הנתונים דרך איש-באמצע.

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

ישנן מספר סיבות למשלוח נתונים מוצפנים דרך חיבור מוצפן:

• גם אם הצפנת החיבור נשברה (למשל MitM, אפשרי אך מאתגר עם HTTPS, ומוביל ל יירוט של כל הנתונים המועברים), הנתונים עדיין מוצפנים
• לא ניתן לסמוך על שרת HTTPS, והוא אחראי על העברת הנתונים לשרת אחר
• באופן דומה, שרת HTTPS העבירו את הנתונים לשרת אחר באמצעות חיבור לא מוצפן, והלקוח הצפין את הנתונים לפני השידור מפחית את העומס על שרת ה- HTTPS, שאם לא כן, יהיה עליו להצפין את הנתונים מכל הלקוחות במקום להיות מסוגל להעביר אותם ישר

ערפול API

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

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

דוגמאות יכולות להיות משחק מבוסס אינטרנט, שמגיש לשחקנים ציון גבוה. p>

אם הבנתי נכון, רשת Tor עובדת כך:

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

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

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

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

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

הסיבה העיקרית להצפנה מרובת רמות היא הפרדת דאגות.

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

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

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

סיבה משנית להצפנה מרובה היא כביטוח במקרה שאחת משכבת ​​ההצפנה היא שָׁבוּר. IMO, זו סיבה חלשה בהרבה מכיוון שאתה צריך לקחת בחשבון שכל שכבה נוספת מיותרת מגדילה את מורכבות המורכבות והמורכבות היא האויב של הביטחון.

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

כדי להימנע מבעיות עם תאימות PCI, כאשר היזם מעוניין להשתמש בשער התשלומים ומציב את הציות על הצד השלישי.

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

ראוי לציין כי זה נמצא על גבי HTTPS . כך האתר אפילו לא רואה את הנתונים הלא מוצפנים, רק את המשתמש ואת שער התשלומים.

דוגמה עם שער התשלומים של עץ המוח: https://www.braintreepayments.com/blog/ הצפנה בצד הלקוח /

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

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

הצפנה כפולה (או משולש או ארבע או ..) יכולה להיות דרך טובה להימנע מהטלת כל הביצים שלך. בסל אחד.

לא בדיוק בעיית HTTPS, אך מקרה שימוש חוקי אחר של הצפנה כפולה משמש בדרך כלל ב- Tor במקרה "אני לא מאמין לבחור המסירה ורוצה להישאר אנונימי באמצעות צעדים נוספים".

כל "בחור מסירה" מפענח רק את המעטפה כדי לברר את איש המסירה האחר. התקשורת במקרה זה נעטפת ומוצפנת ב- proxy של SOCKS.