לאור כמות המידע האישי שזורם דרך צינורות האינטרנט, אי אפשר להתעלם מהצפנה בקלות, ואסור לעשות זאת. בדפדפנים מודרניים יש כמה מנגנונים שאפשר להשתמש בהם כדי לוודא שהנתונים של המשתמשים מאובטחים במעבר: קובצי cookie מאובטחים ו-Strict Transport Security הם שניים מהמנגנונים החשובים ביותר. הם מאפשרים להגן על המשתמשים בצורה חלקה, לשדרג את החיבורים שלהם ל-HTTPS ולספק ערובה לכך שנתוני המשתמשים אף פעם לא נשלחים ללא הצפנה.
למה כדאי לכם להקפיד על כך? כדאי לשקול את האפשרויות הבאות:
העברת דף אינטרנט בחיבור HTTP ללא הצפנה היא בערך כמו מסירת מעטפה לא חתומה לאדם הראשון שרואים ברחוב שנראה שהוא הולך לכיוון הדואר. אם תהיו ברי מזל, היא תיקח את החבילה עד ליעדה בעצמה, או שתמסור אותה לאדם הבא שהיא תראה שנוסע בכיוון הנכון. אותו משתמש יכול לעשות את אותו הדבר, וכן הלאה.
רוב האנשים הלא מוכרים בשרשרת הזו הם מהימנים, והם אף פעם לא יעיינו במכתב הפתוח שלכם או ישנו אותו. עם זאת, ככל שהמכתב עובר יותר ידיים, כך גדל מספר האנשים שיש להם גישה מלאה למכתב שאתם שולחים. בסופו של דבר, סביר להניח שהנמען המיועד של המכתב יקבל משהו בדואר, אבל השאלה הפתוח היא אם זה יהיה הדבר ששלחתם מלכתחילה. אולי כדאי היה לאטום את המעטפה…
גורמים מקשרים
בין שזה טוב ובין שזה רע, חלקים גדולים באינטרנט מסתמכים על האמינות של זרים. השרתים לא מחוברים זה לזה ישירות, אלא מעבירים בקשות ותשובות מרשת לרשת, במשחק טלפון עצום.
אפשר לראות את הצעדים האלה בפעולה באמצעות traceroute. המסלול מהמחשב שלי אל HTML5Rocks נראה בערך כך:
$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
1 router1-lon.linode.com (212.111.33.229) 0.453 ms
2 212.111.33.233 (212.111.33.233) 1.067 ms
3 217.20.44.194 (217.20.44.194) 0.704 ms
4 google1.lonap.net (193.203.5.136) 0.804 ms
5 209.85.255.76 (209.85.255.76) 0.925 ms
6 209.85.253.94 (209.85.253.94) 1.226 ms
7 209.85.240.28 (209.85.240.28) 48.714 ms
8 216.239.47.12 (216.239.47.12) 22.575 ms
9 209.85.241.193 (209.85.241.193) 36.033 ms
10 72.14.233.180 (72.14.233.180) 43.222 ms
11 72.14.233.170 (72.14.233.170) 43.242 ms
12 *
13 lb-in-f102.1e100.net (173.194.71.102) 44.523 ms
13 קפיצות זה לא רע בכלל. עם זאת, אם שולחים בקשות דרך HTTP, לכל אחד מהנתבים הביניים האלה יש גישה מלאה לבקשות ולתגובות של השרתים. כל הנתונים מועברים כטקסט ללא הצפנה, וכל אחד מהגורמים המתווך יכול לפעול כאדם באמצע, לקרוא את הנתונים שלי או אפילו לבצע בהם שינויים במהלך ההעברה.
גרוע מכך, קשה מאוד לזהות חסימות כאלה. תגובת HTTP ששונתה בזדון נראית בדיוק כמו תגובה תקינה, כי אין מנגנון שמאפשר לוודא שהנתונים שהתקבלו הם _בדיוק_ הנתונים שנשלחו. אם מישהו יחליט להפוך את האינטרנט שלי בראש ובראשונה בשביל הכיף, אין לי הרבה מה לעשות.
האם זו שיחה מאובטחת?
המעבר מ-HTTP בטקסט ללא הצפנה לחיבור HTTPS מאובטח הוא ההגנה הטובה ביותר מפני גורמים מקשרים. חיבורי HTTPS מצפינים את כל הערוץ מקצה לקצה לפני שליחת הנתונים, כך שמכונות שנמצאות בינכם לבין היעד לא יכולות לקרוא או לשנות נתונים במעבר.
האבטחה ש-HTTPS מספק מבוססת על הרעיון של מפתחות קריפטוגרפיים ציבוריים ופרטיים. ניתוח מעמיק של הפרטים (למרבה המזל) חורג מהיקף המאמר הזה, אבל ההנחה המרכזית היא פשוטה למדי: אפשר לפענח רק נתונים שהוצפנו באמצעות מפתח ציבורי נתון באמצעות המפתח הפרטי התואם. כשדפדפן מתחיל לחיצת יד של HTTPS כדי ליצור ערוץ מאובטח, השרת מספק אישור שמספק לדפדפן את כל המידע הדרוש כדי לאמת את הזהות שלו, על ידי בדיקה שהמפתח הפרטי המתאים נמצא בידי השרת. כל התקשורת שמתחילה מנקודה זו ואילך מוצפנת באופן שמוכיח שהבקשות נשלחות לשרת המאומת והתשובות מתקבלות ממנו.
לכן, השימוש ב-HTTPS מעניק לכם გარკვეיות מסוימת לגבי העובדה שאתם משוחחים עם השרת שאתם חושבים שאתם משוחחים איתו, ושאף אחד אחר לא מקשיב או משחק בביטים בקו. סוג ההצפנה הזה הוא תנאי הכרחי לאבטחה באינטרנט. אם האפליקציה שלכם לא מועברת כרגע דרך HTTPS, היא חשופה להתקפות. לפתרון הבעיה. ב-Ars Technica יש מדריך מצוין לקבלה ולהתקנה של אישור (בחינם), שאפשר להיעזר בו כדי לקבל פרטים טכניים. ההגדרות משתנות מספק לספק ומשרת לשרת, אבל תהליך הבקשה לקבלת אישור זהה בכל מקום.
אבטחה כברירת מחדל
אחרי ששולחים בקשה לאישור ומתקינים אותו, חשוב לוודא שהמשתמשים נהנים מהעבודה הקשה שלכם: מעבירים את המשתמשים הקיימים לחיבורי HTTPS באופן שקוף באמצעות הקסם של הפניה אוטומטית (redirect) ל-HTTP, ומוודאים שקובצי cookie נשלחים רק דרך חיבורים מאובטחים.
בדרך הזו, בבקשה
כשמשתמש נכנס לכתובת http://example.com/, מפנים אותו לכתובת https://example.com/ על ידי שליחת תגובה 301 Moved
Permanently עם כותרת Location מתאימה:
$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/
אפשר להגדיר בקלות הפניה אוטומטית כזו בשרתים כמו Apache או Nginx.
לדוגמה, הגדרת Nginx שמעבירה מ-http://example.com/ ל-https://example.com/ נראית כך:
server {
listen [YOUR IP ADDRESS HERE]:80;
server_name example.com www.example.com;
location "/" {
rewrite ^(.*) https://www.example.com$1 permanent;
}
}
נעילת קובצי ה-cookie
קובצי cookie מאפשרים לנו לספק למשתמשים חוויית כניסה חלקה באמצעות פרוטוקול HTTP ללא מצב. נתונים שמאוחסנים בקובצי Cookie, כולל מידע אישי רגיש כמו מזהי סשנים, נשלחים עם כל בקשה, ומאפשרים לשרת להבין לאיזה משתמש הוא משיב כרגע. אחרי שאנחנו מוודאים שהמשתמשים נכנסים לאתר שלנו דרך HTTPS, אנחנו צריכים לוודא גם שהמידע האישי הרגיש שנשמר בקובצי cookie מועבר רק דרך חיבור מאובטח, ושאף פעם הוא לא נשלח ללא הצפנה.
הגדרת קובץ cookie בדרך כלל כוללת כותרת HTTP שנראית בערך כך:
set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT
כדי להורות לדפדפן להגביל את השימוש בקובץ ה-cookie לאבטחת סשנים, אפשר להוסיף מילת מפתח אחת:
Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure
קובצי cookie שהוגדרו עם מילת המפתח secure לא יישלחו לעולם דרך HTTP.
סגירת החלון הפתוח
המשמעות של הפניה שקופה ל-HTTPS היא שברוב הזמן שבו המשתמשים נמצאים באתר, הם משתמשים בחיבור מאובטח. עם זאת, היא משאירה חלון הזדמנויות קטן למתקפה: חיבור ה-HTTP הראשוני פתוח לרווחה וחשוף לחילוץ של SSL ולהתקפות קשורות. מאחר שלאדם בתווך יש גישה מלאה לבקשת ה-HTTP הראשונית, הוא יכול לשמש כשרתי proxy ביניכם לבין השרת, ולשמור אתכם בחיבור HTTP לא מאובטח ללא קשר לכוונות של השרת.
כדי לצמצם את הסיכון למתקפה מהסוג הזה, אפשר לבקש מהדפדפן לאכוף את HTTP Strict Transport Security (HSTS). שליחת הכותרת Strict-Transport-Security HTTP מורה לדפדפן לבצע את ההפניה האוטומטית מ-HTTP ל-HTTPS בצד הלקוח, בלי לגעת ברשת (השיטה הזו גם משפרת את הביצועים, כי הבקשה הטובה ביותר היא זו שלא צריך לשלוח):
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
בדפדפנים שתומכים בכותרת הזו (נכון לעכשיו Firefox, Chrome ו-Opera: פרטים ב-caniuse) תופיע הערה על כך שהאתר הספציפי הזה ביקש גישה ב-HTTPS בלבד. כלומר, לא משנה איך המשתמש מגיע לאתר, הוא יבקר בו דרך HTTPS. גם אם היא תקליד http://example.com/ בדפדפן, היא תגיע ל-HTTPS בלי ליצור חיבור HTTP. יתרה מכך, אם הדפדפן מזהה אישור לא תקין (שעשוי להיות ניסיון להתחזות לזהות השרת), המשתמשים לא יוכלו להמשיך דרך HTTP. זהו מצב של הכל או כלום, וזה מצוין.
הדפדפן יפוג את התוקף של סטטוס ה-HSTS של השרת אחרי max-age שניות (כחודש בדוגמה הזו). כדאי להגדיר ערך גבוה יחסית.
אפשר גם לוודא שכל תת-הדומיינים של המקור מוגנים על ידי הוספת ההוראה includeSubDomains לכותרת:
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
המשיכו בבטחה
HTTPS היא הדרך היחידה להבטיח שהנתונים שאתם שולחים מגיעים לידי המקבל המיועד ללא שינוי. כדאי להגדיר חיבורים מאובטחים לאתרים ולאפליקציות כבר היום. זהו תהליך פשוט למדי, שיעזור לכם לשמור על אבטחת הנתונים של הלקוחות. אחרי שתגדירו ערוץ מוצפן, עליכם להפנות את המשתמשים באופן שקוף לחיבור המאובטח הזה, ללא קשר לאופן שבו הם מגיעים לאתר, על ידי שליחת תגובה מסוג HTTP 301. לאחר מכן, מוסיפים את מילת המפתח secure כשמגדירים את קובצי ה-cookie, כדי לוודא שכל פרטי הסשן הרגישים של המשתמשים יישלחו רק דרך החיבור המאובטח הזה.
אחרי שמשלימים את כל הפעולות האלה, חשוב לוודא שהמשתמשים שלכם אף פעם לא יוצאים מהתמונה בטעות: כדי להגן עליהם, צריך לוודא שהדפדפן שלהם פועל כמו שצריך על ידי שליחת כותרת Strict-Transport-Security.
הגדרת HTTPS היא לא עבודה קשה, והיא מניבה יתרונות עצומים לאתר ולמשתמשים בו. זה שווה את המאמץ.
משאבים
- StartSSL מציעה אישורים בחינם עם אימות דומיין. אי אפשר להתחרות בחינם. כמובן שאפשר לשדרג לרמות אימות גבוהות יותר, במחירים סבירים.
- בדיקת שרת SSL: אחרי שמגדירים HTTPS בשרתים, בודקים שהכול נעשה כמו שצריך באמצעות בדיקת השרת של SSL Labs. תקבלו דוח מפורט שיציג אם הכול פועל כמו שצריך.
- כדאי לקרוא את המאמר האחרון של Ars Technica בנושא אבטחת שרת האינטרנט באמצעות SSL/TLS כדי לקבל פרטים נוספים על הרקע והפרטים הטכניים של הגדרת שרת.
- כדאי לעיין במפרט של HTTP Strict Transport Security (RFC6797) כדי לקבל את כל המידע הטכני האפשרי על הכותרת
Strict-Transport-Security. - אחרי שתצברו ניסיון, תוכלו להודיע לאנשים שאפשר לגשת לאתר שלכם רק באמצעות קבוצה ספציפית של אישורים. יש עבודה מתמשכת ב-IETF שתאפשר לכם לעשות זאת באמצעות הכותרת
Public-Key-Pins. זה עדיין בשלב מוקדם, אבל מעניין ומומלץ לעקוב אחריו.