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

1. תקשורת לא מאובטחת: הבעיה עם HTTP

בשנת 1991, כשטים ברנרס לי המציא את פרוטוקול HTTP העולם נראה אחרת לגמרי והאינטרנט נראתה אחרת לגמרי. ה ISP המסחרי הראשון בארה"ב נקרא The World והוא נפתח ב 1989. אבל הרשת עצמה היתה קיימת עוד משנות ה-60 ובתודעה של רוב המשתמשים היא היתה רשת סגורה לצבא, אוניברסיטאות וארגוני ממשלה. לכן מפת האיומים שהיתה לטים ברנרס לי בראש ממש לא כללה חשש מהאזנות. יותר מזה, גם לא היה צורך להאזין לאף אחד - ב HTTP ממילא לא היתה אפשרות להזדהות ולכן כל המידע בכל האתרים היה פתוח.

רק ב 1994 נטסקייפ התחילו לשלב תמיכה בעוגיות בדפדפן ורק ב 1999 נכתב RFC2617 שהגדיר מה זה HTTP Authentication.

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

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

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

עם החדירה של רשתות WiFi לחיינו הרף ירד משמעותית. מספיק היה לשבת בבית קפה עם רשת ויפי כדי שמישהו מהשולחן ליד יוכל לראות את כל מה שאתה עושה באתרים ואת כל הסיסמאות ונתוני הגישה שהמחשב שלכם שולח.

2. הפיתרון? הצפנה!

לכן ב 1994 יחד עם פיתוח ה Cookeies וההבנה שאנשים הולכים להשתמש בזה כדי ליצור אתרים עם מידע אישי, הוסיפו נטסקייפ לדפדפן אפשרות לתקשורת מאובטחת כך שכל בקשות ה HTTP יוצפנו עם פרוטוקול שנקרא SSL. היום הפרוטוקול הזה התפתח וכשאנחנו מדברים על HTTPS היום אנחנו מדברים על העברת תקשורת HTTP בפרוטוקול שנקרא TLS או בשמו המלא Transport Layer Security.

ה RFC שמגדיר בצורה רשמית את HTTPS קיבל את המספר 2818 ויצא במאי 2000.

פרוטוקול HTTPS מספק מענה לצרכים הבאים:

1. הזדהות - הצורך לדעת עם מי אנחנו מדברים.

2. הצפנה - הצורך לשלוח מידע כך שרק הצד השני יוכל לקרוא אותו.

3. שלמות - הצורך לוודא שהמידע ששלחנו הגיע במלואו וללא שינוי לצד השני.

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

3. הצפנה אסימטרית זה לא מספיק

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

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

הנה תיאור לא מדויק של המנגנון אבל שמעביר את הרעיון:

במנגנון התעודות יש חברה (למעשה הרבה חברות) שמתפקדת בתור Certificate Authority. נקרא לה VeriSign. החברה הזאת לא מפעילה שרת שמחלק מפתחות ציבוריים, כי שרת כזה יהיה יקר לתפעול. במקום, החברה הנפיקה לעצמה זוג מפתחות כמו זה שמשמש להצפנה רק שהפעם נקרא למפתח הציבורי באמצעותו מצפינים "מפתח הצפנה" ולמפתח הפרטי באמצעותו מפענחים את ההודעה "מפתח הפיענוח".

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

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

4. בעיה 1: מי נתן לך תעודה?

הבעיה הראשונה קשורה לאותה וריסיין. יש היום כ-150 חברות הנפקת תעודות כאלה, אתם יכולים לראות את הרשימה המלאה כאן:

https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport

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

ארגוני ביון או ממשלות יכולים לפרוץ לחברה כזאת. כך קרה למשל לחברת DigiNotar שהיתה CA הולנדי מוכר עד שב 2011 ממשלת איראן פרצה אליה כדי שתוכל לייצר תעודות מזויפות. אפשר לקרוא עוד על הסיפור כאן:

https://en.wikipedia.org/wiki/DigiNotar

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

https://en.wikipedia.org/wiki/StartCom

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

5. בעיה 2: תראה רגע מה כתוב על התעודה?

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

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

https://www.аррlе.com/

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

לשמחתנו דפדפנים רבים כוללים מנגנון Anti Phishing מובנה ודפדפני כרום וספארי יציגו לכם את ה Punicode Domains כמו הזיוף הזה של אפל בצורה מפורשת כך שלא תתבלבלו.

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

6. בעיה 3: מי נתן לך דפדפן?

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

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

https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/

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

https://en.wikipedia.org/wiki/Superfish

7. איך מקבלים תעודה

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

בשביל להתחיל לעבוד ב HTTPS אצלכם באתר תצטרכו לבצע מספר פעולות פשוטות:

1. תצטרכו למצוא CA חביב שינפיק לכם תעודה. זה פשוט קובץ שאתם שמים על השרת.

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

3. אחרי שלקחתם את התעודה אתם שמים אותה על שרת הווב שלכם. אם יש שרת יחיד אפשר לשים עליו את התעודה. אם יש לכם Load Balancer ורשת יותר מתוחכמת נשים בדרך כלל את התעודה על ה Load Balancer כך שהתקשורת מבחוץ לרשת שלנו תהיה מוצפנת, אבל התקשורת בתוך הרשת הפנימית שלנו תהיה גלויה. כך ה Load Balancer יוכל להבין מה הבקשה ולטפל אחרת בבקשות מסוימות (למשל עבור טיפול ב Sticky Cookie).

4. אם אתם צריכים לשנות בצורה דינמית את רשימת התעודות שהשרת שלכם מכיר תצטרכו שרת ווב שתומך בטעינה דינמית של תעודות, ותוכלו לעבוד רק עם דפדפנים שתומכים בפיצ'ר (זה נקרא SNI). אני ממליץ על שרת Haproxy שתומך בפיצ'ר זה וכאן יש רשימה של דפדפנים תומכים אבל אם אתם מתעצלים להיכנס אספר בקצרה שזה כולם מלבד IE6:

https://caniuse.com/#search=sni

8. אז אחרי הכל - כדאי?

כן. באמת. ב 2014 הקימו יצרניות הדפדפנים הגדולות ארגון ללא כוונת רווח שנקרא Let's Encrypt והם מספקים תעודות לכל מי שרוצה ובצורה אוטומטית לגמרי. יש להם סקריפט שאתם יכולים להוריד ולהתקין על השרת שלכם שנקרא certbot ואתם פשוט מפעילים אותו והוא אוטומטית מאמת את הדומיין, מייצר ומוריד תעודה חתומה ומעדכן את הגדרות השרת.

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

רוצים לשמוע עוד? לשאול שאלות? היום בעשר אעביר וובינר על הנושא. מוזמנים עדיין להצטרף כאן:

https://www.tocode.co.il/workshops/68

נתראה ינון