מבוא לאבטחת מידע ("סייבר" ושטויות כאלו…)

אבטחת מידע (Information Security) או בקיצור InfoSec היא הפרקטיקה של הגנה על מידע במערכות, בעיקר מערכות ממוחשבות – אך לא רק.

ממש בשנים האחרונות, הפכו אנשי האבטחה ("גננים") למשהו אחר לגמרי: אנשי סייבר ("מהנדסי נוף"). Fancy Name שהוא בעצם אותו הדבר.

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

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

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

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

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

קצת פרספקטיבה היסטורית

אני ממליץ לכם להשקיע שלוש דקות לצפות בסרטון הקצבי הבא: https://vimeo.com/55183725

הסרטון מתאר את המציאות בשנת 2010 ונוצר ע"י חברת-אבטחה בשם ArcSight שנרכשה מאז ע"י HP. הוא מפגין כמה מהסיכונים המרכזיים באינטרנט לאותה התקופה.

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

אני רוצה להתייחס לכמה אמירות מהסרטון:

"10,000,000 (עשר מיליון) התקפות מתבצעות ביום על מחלקת האנרגיה בארה"ב"

ההגדרה של התקפה כאן היא נכונה "משפטית", אך סביר שתעתע בצופה שאינו מומחה אבטחה.
התקפה שמתייחסים אליה כאן – היא קריאה בודדת ברשת (פרוטוקולי HTTP, ICMP, TCP, וכו') שכוונתה לגרום נזק. זו יכולה להיות קריאת Scanning (אין בעיה ל Scanner לשבת 24/7 ולשלוח קריאות בכדי ללמוד את הרשת והמערכת שלנו. לרוב הוא יעשה אותן בקצב "מנומס" בכדי שלא יבחינו בו), או ניסיון אקראי לפנות ל API עם פרמטרים שגויים ולראות מה התוצאה.

כלומר: 10 מיליון קריאות עוינות על מחלקת האנגרגיה של מדינה – זה לא כ"כ הרבה: אלו הם לא "10 מיליון תוקפים שניסו באותו היום לפרוץ למערכת". בכל זאת:

כ 30% מהתעבורה באינטרנט היא תעבורה עוינת (מקור). 2015 הייתה השנה הראשונה מזה זמן-רב שיותר תעבורה באינטרנט נוצרה ע"י בני-אדם, מאשר ע"י bots.
חשוב גם לציין שרוב התעבורה העויינת איננה יעילה – אלו "יריות באוויר" שרק חלק קטן מהן גורם לנזק כלשהו. בכל זאת – המספרים הם מפחידים!

זה לא משחק מחשב!
בקרו ב http://map.norsecorp.com על מנת לראות מדגם מזערי, אך עדני בזמן אמת – של traffic עויין שעובר באינטרנט.
הטראפיק הזה לא עוצר, ולא פוחת, 24/7.

"59% מעובדים שעוזבים את החברה גונבים נתונים בדרכם החוצה"

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

אני מניח שהנתון המאוזן הוא ש "59% אחוז מהעובדים שעוזבים לוקחים איתם גם נתונים ששייכים לארגון". מי מאיתנו לא עזב מקום עבודה ולא שמר את תיקיית המסמכים הפרטית שלו? האם בתיקייה הזו אין גם גם כמה מסמכים לא-פרטיים? – כנראה שכן. עדיין, ברוב הכמעט-מוחלט של המקרים לא יעשה שימוש לרעה בנתונים הללו.

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

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

"אם לא – אז שימו כאן 100,000$ ברגע זה, ואנחנו נדאג שזה לא יקרה! יקרה פחות" – היא האמירה שסוגרת את העסקה (לרוב האמירה תהיה קצת יותר מעודנת, כמובן).
מחיר נוסף, שלא תמיד נלקח בחשבון הוא העיכוב שנוצר בזרימת העבודה – בעקבות אמצעי אבטחה ("controls"). אמצעי אבטחה לרוב מוסיפים תקורה על העבודה השוטפת בארגון. לא המון – אבל קצת, וגם את הכמות הזו חשוב לקחת בחשבון.

"385 חברות בארה"ב חוו פריצה משמעותית למערכות שלהם ב 2010"

המספר הזה דווקא לא נשמע כ"כ מרשים. יש לכך 2 סיבות:

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

"בתי חולים בקליפורניה נקנסו ב $675K על כך שנכשלו בעקביות להגן על מידע של מטופלים"

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

"80% מהבנקים לא מצליחים לעצור הונאות לפני שהכסף מועבר"

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

חשוב לי להזכיר שהנטייה הטבעית לחשוב על אבטחת מידע כ Prevention – חסימת התוקף מבעוד מועד, אבל קשת הפעולה של אבטחת המידע היא רחבה הרבה יותר:

מודיעין – להאזין לתוקפים וללמוד מה הם מתכננים מבעוד מועד. יש חברות שסורקות פורומים של תוקפים ותמורת תשלום – יעדכנו אתכם במגמות העדכניות אצל התוקפים ו/או כל שביב מידע שהם נתקלו בו שקשור לחברה שלכם.
Prevention – בניית קווי הגנה נגד תוקפים פוטנציאלים. שם מושקע רוב המאמץ.
Reaction – היכולת להגיב בזמן שהתקפה מתבצעת, ולצמצם את נזקיה. אם ע"י מערכות Alerts ותגובה ידנית, ואם ע"י סקריפטים של תגובה אוטומטית.
Forensics ("זיהוי פלילי") – איסוף ראיות על התוקפים (ע"י audits ולוגים, למשל) בכדי לפעול נגדם בחזרה. אלו יכולים להיות צעדים משפטיים, או התקפת-נגד.
חשבו על מערכת המשפט: היא לא מונעת שום פשע, אך עדיין יש לה תרומה חשובה מאוד בצמצם הפשע בכך שהיא מענישה פושעים לאחר שהעברה כבר בוצעה.

לסיכום ביניים:

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

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

מחירון לפרטי כרטיסי אשראי גנובים. מקור: http://cybersolace.co.uk/2016/04/06/hacking-underground-market

מושגים בסיסיים

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

פגיעות / חולשה (vulnerability) היא תכונה של המערכת (מערכת תוכנה או מערכת אנושית) שתוקף יכול לנצל לרעה. פגיעויות ניתן "לחסום"- אך יש לכך מחיר. לעתים קרובות לא משתלם מבחינה עסקית או מבחינת "איכות החיים" לנטרל את הפגיעות – ולכן מקבלים אותה גם כאשר היא ידועה.
- למשל: למטוסים יש פגיעות שניתן לחטוף אותם ולרסק אותם. ניתן "לבטל" את הפגיעות הזו ע"י הפסקת שימוש במטוסים ע"י האנושות – מה שכנראה לא יקרה. אלטרנטיבה נוספת: ע"י בניית מטוסים מצופים בחומר חסין-התרסקות שייקר את עלות הטיסה פי 2000 – מה שגם כנראה לא יקרה.
- מה שכן עושים הוא למתן (mitigate) את הפגיעות ע"י אמצעים כלכליים יותר: אבטחה בשדות תעופה, הגנה פיסית טובה יותר על תא הטייס, נהלי אבטחה מחמירים יותר במהלך הטיסה, וכו'.
איום (threat) הוא סוג מסוים של התקפה אפשרית. פעולה שתוקף יכול לנקוט.
סיכון (risk) הוא הסבירות שאיום מסוים יתממש. בכדי שאיום יתממש יש גם צורך בתוקף שיממש אותו – וגם פגיעות שתאפשר את ההיתכנות שלו.
- למשל: תוקף יכול לבצע "חטיפה והתרסקות של מקרר ביתי", אך מכיוון שלמקרר ביתי אין את הפגיעות של "התרסקות" – האיום לא יכול להתממש. למקרר ביתי כן יש את הפגיעות של "חטיפה", אבל המוטיבציה לכזו תקיפה היא כ"כ קטנה כך שאנו יכולים בקלות לקבל עלינו את הסיכון הזה.

2016

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

בלי מאמץ מיוחד, קפצתי לאתר Hackmageddon שמבצע סיכום דו-שבועי של התקפות שהתפרסמו באותה התקופה. הנה כמה highlights ממה שמצאתי במהלך חודש (שבועיים מפברואר + שבועיים ממרץ), ויחסית ל Highlights של 2010:

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

הנה כמה דוגמאות שצצות מהזיכרון:

הניתוח של אולה ביני כיצד עובד תור (כלי לאנונימיות באינטרנט)
המאמר The Basics of Web Application Security שנכתב בצורה מתגלגלת בימים אלו בבלוג של מרטין פאוולר. מאמר פרקטי.
רן בר-זיק ("אינטרנט ישראל") שכתב בעקביות מאמר בשנה על אבטחת-מידע בבלוג – אך מתחילת 2016 הספיק כבר לכתוב ארבעה מאמרים בנושא

שוב: המאמרים הללו נכתבו ע"י אנשי תוכנה – לא אנשי אבטחה.

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

לחצו להגדלה

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

סוגי תוקפים

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

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

גם את מידת המומחיות התוקפים ניתן לאפיין ולסווג:

Casual Person – אנשים ללא מומחיות טכנית עדיין יכולים לבצע התקפות. דוגמה קלאסית: Insiders.
Script Kiddies – אנשי בעלי יכולות טכניות בסיסיות, המשתמשים (הורידו באינטרנט) בכלים אוטומטיים שמישהו אחר הכין על מנת להפעיל התקפות. הם לרוב לא יודעים כיצד הכלים הללו עובדים אך משמשים כמכפיל כח למי שבנה את הכלי.
תוקפים ברמת מומחיות בינונית – אנשים בעלי יכולת לכתוב סקריפטים / קוד והבנה בסיסית בעולם התוכנה, היכולים להמציא התקפות משלהם – לרוב לא כ"כ מתוחכמות או פשוט וריאציה משופרת של התקפה קיימת.
"האקר" – זהו במקור תואר כבוד למקצועני תוכנה ברמה הגבוהה ביותר, בעלי הבנה עמוקה בכתיבת קוד, מערכות הפעלה, רשתות נתונים, בסיסי נתונים וכו' אשר ממציאים ומיישמים התקפות מורכבות ומתוחכמות. את הכלים שלהם הם לעתים מפיצים לכל דורש – וכך מאפשרים את הקטגוריה של ה Script Kiddies.
המונח "האקר" כבר איננו באמת אקסלוסיבי ומשמש סבים רבים לתאר את הנכנדים שלהם שיודעים להשתמש בגוגל "הוא מצא לבד את האתר של ביטוח לאומי! הוא ממש האקר!!".

מחירון לשירותי "האקינג" כלליים. מקור: http://cybersolace.co.uk/2016/04/06/hacking-underground-market

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

איומים פוטנציאלים מאדם ללא מומחיות טכנית:
- גניבת רוחב פס – שכן או עובר אורח ש"זולל" לנו חלק מגלישת האינטרנט.
- SPAM – שליחת מיילים ללא הסכמת המקבל ובכמויות גדולות.
- גניבת זהות נקודתית – פרסום פוסטים באתרים / רשתות חברתיות בשם אדם אחר וללא ידיעתו / הסכמתו.
איומים מצד משתמש טכני פשוט שמשתמש בכלים שניתן להוריד באינטרנט (מה שנקרא Scipt Kiddie):
- האזנה לתקשורת אלחוטית של משתמשים אחרים ברשת Wi-Fi או בתא סלולרי זהה.
- גילוי ססמה של משתמש אחר ע"י keylogger (רכיב שניתן לקנות באינטרנט ומחברים בין המקלדת למחשב על מנת להקליט את ססמת החיבור למחשב)
- ניחוש ססמה של משתמשים לאתרים ע"י שימוש ב Dictionary Attack (ניסוי כמה אלפי הססמאות הנפוצות ביותר).
איומים מצד "פושע אינטרנט" (cyber criminal) – אדם בעל נכונות לקחת סיכונים ובעל רמת מומחיות בינונית:
- Rogue security software – היכולת לספר לאדם שהמחשב שלו נמצא בסיכון אבטחה (זה יכול להיות סתם פופ-אפ מעוצב באתר) ולדרוש ממנו תשלום על מנת לטפל בה. מסתבר שזה שוק לא קטן…
- טרנד חם חם היום הוא ה"כופרה" (ransomware) שעשתה לאחרונה עליה משמעותית לקהל דוברי העברית. תוכנה שמצפינה למשתמש את הקבצים במחשב – ודורשת תשלום תמונת מפתח ההצפנה.
  - אפשר לקרוא עוד (בעברית) בכלכליסט, גיקטיים, ועוד לינק בגיקטיים.
- הפצת תוכנות זדוניות (malware – "נוזקה") למשתמשי קצה. למשל: העלאת משחק או תוכנה נגועה לאתר שיתוף קבצים. התוכנה הזדונית, ברגע שהופעלה יכולה לשלוח לתוקף מידע שנמצא על המחשב (למשל: תיקיית "My Documents" בחלונות) – בתקווה "לדוג" משהו שימושי, או לשמש כבסיס להתקפת Denial of Service ואז בקשת כופר.
- Phishing – התחזות לאתר לגיטימי, שלעתים נראה 1:1 כמו האתר אליו הם מתחזים על מנת לגנוב מהמשתמשים את הססמאות שלהם (או מקבילה אחרת). אל האתר המזויף ניתן להגיע ע"י קישור בפורום או במייל (קל לביצוע) או ע"י רישום של כתובת דומה מאוד לאתר המקורי שמשתמשים אקראיים יכולים להתבלבל.
  - בווריאציה אחרת: מספיק ה click של המשתמש על מנת לגנוב session של המשתמש לאתר – וביצוע פעולות באתר "בשם המשתמש" (להלן CSRF, Clickjacking)
איומים מצד "האקרים":
- גניבת זהות מלאה: גניבת ושינוי ססמאות לאתרים המרכזיים של האדם (Gmail, פייסבוק, וכו'). מכאן יש קשת רחבה של אפשרויות: שליטה על המייל מאפשר בד"כ אתחול ססמה וקבלת סיסמה חדשה לאתרים רבים. ניתן לגנוב כסף ושירותים, ניתן לדרוש כופר להחזרת הזהות, או לבצע פעולות לפגוע במוניטין (reputation) של האדם שהותקף – כאשר אותו האדם יתקשה להוכיח שלא הוא העומד מאחרי המעשים.
- גניבת כמויות של נתונים פרטיים של משתמשים מאתרים עסקיים – ופגיעה במוניטין שלהם, עד פגיעה חמורה ביכולת שלהם להמשיך ולעשות עסקים.
- בעצם… כל מה שתוכנה יכולה לעשות. בהינתן ההשקעה מצד התוקף, פגיעויות קיימות מצד המותקף, וקצת מזל לטובתו של התוקף.

כדאי לזכור שלאינטרנט יש שלוש תכונות שהופכות אותו לסביבה פורה כ"כ להתקפות:

אנונימיות – ניתן לבצע פעולות ברשת האינטרנט בצורה אנונימית. קשה מאוד לאתר את התוקף, וכך מוסרים מהתוקף חלק מהסיכונים של מערכות אכיפת החוק.
גישה עולמית – ניתן מכל יעד בעולם, לתקוף כל יעד אחר שמחובר באינטרנט.
הפורץ המומחה מערבות רומניה היה יכול לתקוף רק כמה יישובים בסביבה, ולא את הבית שלי שבישראל. דרך האינטרנט – כל בית בעולם הופך ל"יעד נגיש".
התוקף יכול להתגונן ע"י חוקים מקומיים ו/או חוסר שיתוף פעולה של הרשויות המקומיות.
אוטומציה – אם עליתי על שיטה מוצלחת לפריצת דלתות "פלא-דלת" אוכל להשתמש בשיטה על כחצי-תריסר דלתות ביום, ואולי גם ללמד חבר או שניים את השיטה – כך שיכפילו את התפוקה. אם עליתי על שיטה מוצלחת לפריצה ל Gmail אז אוכל כנראה כל יום לפרוץ לאלפים רבים של חשבונות, וגם אוכל ליצור כלי שעושה זאת ולהפיץ אותו באינטרנט לכל דורש (להלן Script Kiddies).

סיכום

בפוסט זה, דיברנו על המוטיבציה, הקשיים והאתגרים באבטחת מידע ("סייבר, סייבר!") :).
אני חוזר ומדגיש שאבטחת מידע הולכת ומתקרבת להיות משהו שהרבה מאתנו מהנדסי-התוכנה – נידרש אליו בעצמנו, ולא ע"י שליחים ("צוות Security").

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

שיהיה בהצלחה!

HTTPS חלק ג': שיקולים ליישום באפליקציה

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

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

Default Port שונה

בניגוד ל HTTP בו פורט (port) ברירת המחדל הוא 80, ב HTTPS, פורט ברירת המחדל הוא 443. כלומר: אם ב URL של HTTPS לא צויין port – אזי מדובר בפורט 443.

Overhead

כפי שציינתי בפוסט הראשון בסדרה, ל TLS ,בסה"כ, אין תקורה משמעותית:

כ 6% יותר נתונים עוברים ברשת (Headers נוספים וחתימה דיגיטלית מוסיפים, TLS דוחס את ה HTTP headers – מה שקצת חוסך).
שרת מודרני, משקיע כ 2.5ms זמן CPU לצורך TLS handshake של מפתח א-סימטרי ארוך (2K) – לא זמן משמעותי. בעבר היה מקובל להוציא את משימת ה TLS handshake לחומרה חיצונית (Load Balancer או CDN) שעשתה עבודה זו בעלות נמוכה יותר – אך נראה שמגמה זו פוחתת.
עבודת ה CPU בצד הלקוח היא לא משמעותית, אולי מלבד מכשירי מובייל (?!)

הנקודה היחידה בה יש הבדל ביצועים משמעותי בין HTTP ל HTTPS הוא יצירת ה connection ההתחלתי.

בפוסט הקודם הסברתי על מנגנון שנקרא Session Ticket שפוטר מהצורך שלנו לבצע TLS handshake לכל connection, כך שבסך הכל אנו יכולים לצפות ל 2 roundtrips נוספים לכל origin איתו אנו יוצרים קשר.

האמנם?

מקור: הבלוג של איליה גריגוריק. שווה לעקוב.

פעמים רבות תתקלו ב TLS שהעלות שלו גדולה מ"התאוריה".

הנה, בתרשים למעלה, רואים גישה לאותו המשאב ב HTTP (שורה עליונה) מול HTTPS (שורה תחתונה), בהינתן RTT של כ 380ms.
ע"פ התאוריה, ניתן לצפון לעלות נוספת של 760ms (פעמיים 380ms) בביצוע TLS handshake, אבל הנה בדוגמה למעלה, ההפרש בפועל הוא כמעט 2000ms, כמעט פי 3 (!) ממה שציפינו.

בפוסט מעניין ויפה איליה גריגוריק מראה כיצד הוא מנתח ומתקן את המצב המתואר לעיל. הוא מזהה, ומתקן, "באפר" (congestion window) שקונפג בשרת בצורה שלא מטיבה עם ה TLS Handshake ואז הוא מוסיף עוד אופטימיזציה של TLS בכדי לצמצם את התקורה ל roundtrip בודד. סה"כ 2000ms הופכים ל 380ms – שיפור מרשים מאוד!
לא צריך להכיר את nginx (השרת המדובר) בכדי לקרוא את הפוסט.

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

עוד גורם שיכול לעכב קריאות HTTPS הוא הפעלה של פרוטוקול בשם Online Certificate Status Protocol (בקיצור: OCSP). זהו פרוטוקול המגביר את אמינות וידוא הזהות של HTTPS – במחיר ביצועים. ע"פ הפרוטוקול, כאשר הדפדפן מקבל Certificate הוא פונה ל CA שהנפיק אותו ומבקש לוודא שה Certificate עדיין תקף. סיבה ש Certificate לא יהיה תקף הוא אם המפתח הפרטי שהיה בשימוש ליצירת ה Certificate נגנב איכשהו, או שהתגלה שבעל ה Certificate הוא מתחזה / פועל בצורה לא כשרה. בחלק ב' של הפוסט שעסק ב Certificates לא כיסיתי את נושא ביטול (revocation) של Certificates – מפאת חוסר מקום / עניין נמוך לקורא.
אם המשתמשים שלכם מפעילים OCSP – אתם יכולים לבדוק את ה CA שלכם, עד כמה הוא מהיר בתגובות שלו לבקשת OCSP באזורים הגאוגרפים הרלוונטיים עבורכם. במידת הצורך, ניתן להחליף CA באחד זמין / מהיר יותר.

שווה לציין ששירותי (CDN (Content Delivery Networks, יכולים לקצר את זמני ה TLS handshake. ל CDNs יש תחנות הקרובות גאוגרפית למשתמש הקצה (ולכן יש להן latency נמוך יותר). משתמש הקצה מבצע TLS handshake מול התחנה הקרובה, של ה CDN, בה כל round-trip הוא זול יותר. מרגע שנוצר ה connection התחנה משתמשת כפרוקסי (מאובטח) לשרת שלכם (על גבי connection מאובטח שנפתח מבעוד מועד) או סתם מעבירה לכם TLS Session Ticket שאתו תוכלו לעבוד. ייתכן ובכלל התוכן זמין על cache של ה CDN ואין טעם להגיע בכלל לשרת היעד.
שירות זה נקרא TLS Early Termination, כאשר הכוונה במילה Termination היא "קיצור המסלול" ולא "סיום התקשורת".
שירות זה, עולה כסף – כמובן, ולא תמיד הוא זמין בכל אתר (או Point of Presence, בקיצור PoP) בה ה CDN פעיל.

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

Connection Termination

מתי שהוא, סיימנו את העבודה המאובטחת מול השרת, ואנו רוצים לסיים את תקשורת ה HTTPS.
דרך מחשבה אחת אומרת כך: "HTTPS חי על גבי TCP, לכן פשוט אפשר לסיים את connection ה TCP בעזרת הודעת TCP FIN – ולסיים עניין".
אולם, הודעת TCP FIN יכולה בעצם להישלח ע"י כל אחד, גם תוקף פוטנציאלי המנסה לשבש את התקשורת. לצורך כך נקבע שתקשורת TLS תסתיים ע"י הודעה ברמת ה TLS (הדלקת flag בשם close_notify) ורק לאחר מכן TCP FIN.

לא לבלבל נושא זה עם Early Termination.

הימנעות מ Mixed Content

אם אתם זוכרים את הפוסט הקודם, נרצה להימנע באתר שלנו מ mixed content: תוכן HTTP בתוך דף HTTPS.
כיצד עושים זאת?
הרבה פעמים ראיתי שפשוט כותבים קוד דומה לזה:

var url = location.url.startsWith('https')) ? HTTPS_URL : HTTP_URL

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

var url = "//myserver/resources/style.css";

זה נראה קצת מוזר, אבל זה תקני לחלוטין. ניתן למצוא עוד פרטים על URL יחסי בפוסט שלי על URLs.
מעניין לציין ששירותים שונים (למשל Google Libraries API) מגישים לנוחיותכם את אותם המשאבים גם על גבי HTTP וגם על גבי HTTPS – וממליצים פשוט להשתמש בסכמה שתארתי.

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

HTTPS כפרוטוקול "VPN"

למרות ש HTTPS הוא לא פרוטוקול VPN, יש לו יתרון שהוא "עובר מסך" אצל firewalls ורכיבי רשת שונים בקלות יחסית:
"אם הצלחת ליצור קשר על גבי TLS עם השרת שלי – אני סומך עליך. אפילו שאין לי מושג (או יכולת לדעת) מה אתם מדברים ביניכם" אומר ה Firewall או ה Transparent Proxy לעצמו.

לאחר שה TLS Connection נוצר הוא מוצפן – ולכן הוא שקול לפרוטוקול בינרי, low level, בין הצדדים. לדוגמה: ניתן להפוך את כיוון התקשורת, להעביר מידע בינרי, להעביר הודעות בחלקים לא מסודרים וכו'. סוג של "TCP על גבי HTTPS" (ה HTTPS משמש בעיקר ל handshake, אח"כ ניתן לרדת חזרה לרמת ה TLS היותר בסיסית).

תכונה זו של HTTPS בשימוש ע"י רכיבים של Content Delivery Networks, תקשורת בין Cloud למערכת ארגונית, ופרוטוקולים כגון SPDY (שהופך להיות HTTP 2.0) ו Web Sockets.

קצרים

האם זה נכון שהדפדפן לא עושה Caching לתוכן HTTPS?
לא. לכו בדפדפן ל about:cache לראות בעצמכם. אפשר בעזרת HTTP Headers מתאימים להגביל את ה Cache ואת אופן השמירה שלו ע"י הדפדפן / ה CDN.
האם רכישת Certificate הוא דבר יקר? אלפי דולרים בשנה?
תלוי בסוג ובמקור ה Certificate, אבל זה יכול להיות גם עשרות דולרים בשנה.
האם זה נכון ש HTTPS מונע Virtual Hosting (לארח כמה אתרים עם Hostnames שונים על אותו שרת פיסי)?
לא. עקרונית יש בעייה, אבל פותרים אותה בעזרת הרחבה ל TLS בשם Server Name Indication (בקיצור SNI). אולי יש פתרונות נוספים.
האם HTTPS מבטיח פרטיות למשתמש הקצה?
נו, אתם אמורים לענות על זה לבד בשלב זה: הוא מגן מפני sniffing ברשת, או בפני התחזות (phishing) – אבל אין לו קשר לאיזה מידע השרת שומר עליכם, כיצד הוא מגן על מידע זה או מה הוא עושה אותו (אולי הוא מפרסם אותו לכולם בגוגל על גבי HTTP …?)

סיכום

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

שיהיה בהצלחה!

—-

לינקים רלוונטים:

HTTPS – חלק ב': אימות זהות

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

תהליך ה Handshake

תקשורת HTTP מתבצעת על גבי TCP connection.
TCP Connection הוא של הסכמה הדדית בין 2 הצדדים כיצד לעבוד, כך שלא יהיה צריך להסכים עם כל הודעה מחדש. הסכמה על TCP connection נעשית בתהליך תלת-שלבי שנקרא "לחיצת ידיים משולשת" (three-way handshake). אני מניח שכל זה מוכר.

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

הנה תקציר תהליך ה TLS handshake:

הודעה 1: Client Hello

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

הודעה 2: Server Hello + Certificate
השרת בוחר בגרסת TLS וההצפנה בהן הוא מעוניין לעבוד (בעצם: המקסימום שהוא תומך) ומצרף את המפתח הציבורי שלו עם Certificate – מספר שדות ("קובץ קצר") שמאמתים את זהותו שלו. מעין "צילום של תעודת הזהות שלו". הקובץ חתום ע"י חתימה דיגיטלית של גורם צד-שלישי מוכר. פרטים נוספים על Certificates – בהמשך הפוסט.

בשלב זה יכול השרת להחליט שהוא רוצה לאמת בעזרת HTTPS Authentication, את זהות המשתמש – ולבקש מה Client חזרה את ה Certificate שלו.

הודעה 3: העברת מפתח סימטרי

ה Client מאמת את ה Certificate של השרת (איך הוא עושה זאת – בהמשך) ומייצר מפתח סימטרי אקראי לצורך ה session הנוכחי עם השרת. אני מניח שמשימת יצירת המפתח הסימטרי ניתנה ל Client בכדי לשפר את ה scalability של השרת ("1000 מעבדים ממוצעים חזקים ממעבד-מפלצת של שרת אחד").

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

הודעה 4: שימוש במפתח הסימטרי לצורך אימות וסיום תהליך ה TLS handshake

בשלב זה השרת משתמש במפתח הפרטי שלו כדי לפענח את ההודעה הקודמת, לחלץ את המפתח הסימטרי – ולעבור להשתמש בו.
ההודעה הראשונה שנשלחת ל Client היא הודעת Finish, מוצפנת במפתח הסימטרי שה Client סיפק, הודעה שעוזרת לודא שתהליך העברת המפתח הסימטרי והשימוש בו ע"פ ההצפנה (chiper) הנכונה – הצליח.

נקודה משמעותית לשים לב אליה היא שאם ב HTTP יצירת connection הייתה תקורה של roundtrip אחד בין הדפדפן לשרת, ב HTTPS – התקורה ליצירת connection היא שלושה roundtrips. בתקשורת בין ישראל לארה"ב – מדובר על בערך שנייה (1000ms לפני שהעברנו ביט אחד של מידע בעל-ערך למשתמש).

Session Tickets
אם אתם זוכרים, הדפדפן פותח עד 6 או 8 connections במקביל מול כל שרת בכדי להאיץ את ההורדה.
כדי לא להגיע למצב בו משלמים את התקורה של TLS handshake מספר רב של פעמים, נוספה יכולת בשם Session Ticket (תקן: RFC 5077) המאפשרת ל connection שני, שלישי וכך הלאה, מול אותו השרת, לעשות שימוש חוזר ב: מפתח הסימטרי, אימות, הסכמה-על-הצפנות וכו'.
עם הודעת ה Finish, השרת שולח Session Ticket (מוצפן) ל Client. כל connection חדש יכול לצרף את ה ticket הזה בכדי "להצטרף" ל HTTPS session שמחזיק השרת – ולחסוך לעצמו תהליך handshake נוסף.

בניגוד ל HTTP שבברירת המחדל הוא stateless (מתנתק אחרי כל response), פרוטוקול HTTPS הוא תמיד statefull (במסגרת ה session).

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

HTTPS Authentication

כפי שציינו, פרוטוקול TLS מספק הצפנה + חתימה דיגיטלית – יכולות שאני לא מוצא הרבה מה להרחיב עליהן. בואו נדבר מעט על Authentication.

TLS תמיד כולל אימות של זהות השרת, והשרת יכול לבקש לאמת גם את זהות משתמש הקצה. מנגנון אימות הזהות ( Authentication) למשתמש הקצה הוא תחליפי לשיטות אחרות כגון SAML 2.0 או OpenID.

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

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

TLS משתמש בסטנדרט שנקרא X.509 לתיאור Certificates – "תעודות" המאמתות את זהותו של אדם / שרת.
ישנם Server Certificates לשרתים וישנם Client Certificates לזיהוי משתמשים. בסה"כ אלו מנגנונים דומים.

X.509 מסתמך על היררכיה של Certification Authorities (בקיצור CA) – גופים (לרוב עסקיים) שמורשים להנפיק Certificates. ה CA המוכר ביותר הוא כנראה זה של חברת VeriSign, שחטיבת אימות הזהות שלה נמכרה לפני כשלוש שנים ל Symantec, אך היא עדיין פועלת תחת השם VeriSign.

VeriSign מאמתת זהות של ארגונים ומנפיקה Certificates לשרתים (ליתר דיוק: ל DNS Entries – השרת הוא רק ה"בחור שנמצא שם כרגע"). היא עושה זאת באופן ישיר וגם הרבה בעזרת ספקי משנה שהיא מסמיכה.

הנה הדרך בה תוכלו לבדוק את ה Certificate של אתר אליו אתם גולשים (דוגמה = כרום):

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

VeriSign בהכרח לא תיתן לחברת סטארטאפ מאוקראינה אימות של Bank Haopalim ל DNS שכתובתו http://www.bankhaopalim.com (זו נראית כמו הכנה להתקפת Phishing! [א]) – צריך להיות קשר ישיר בין השם שנחתם לעסק, ולכתובת ה DNS שאותה מבקשים לחתום.

בפינה הימנית למטה צרפתי עוד דוגמה של Certificate של אתר בשם buy2usa (השייך לחברה buy2) שאומת ע"י CA אחר – במקרה הזה Go Daddy.

ייתכן ותשאלו את עצמכם: מדוע רק לחלק מהאתרים יש רקע ירוק יפה בשם (מסומן בריבוע ירוק בתמונה למעלה)? האם זהו style ב CSS?

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

הנה האופן בו דפדפנים שונים מציגים Extended Validation Certificates:

לכל העניין של חוויית המשתמש יש חשיבות גדולה ב Security – הרי בסוף, אנשים הם חוליה בשרשרת האבטחה. חוליה חלשה – בד"כ.

ספציפית לגבי Extended Validation Certificates (בקיצור: EVC), חוקרים ממייקרוסופט ואוניברסיטת סטנפורד ביצעו מחקר משותף ב 2007 שהראה שמשתמש ממוצע פשוט לא שם לב להדגשה של ה EVC ולא מתייחס אליה כמידע נוסף. מצד שני, אנשים שעברו הדרכה ולמדו לחפש אחרי ההדגשה של ה EVC הצליחו לשים לב אליה ולבצע החלטות טובות יותר בהימנעות מהתקפות phishing.

אז מהם בדיוק ה Certificates ואיך הם מבטיחים וידוא אמין של זהות?

Certificate הוא צירוף של Public Key (א-סימטרי), זיהוי הישות, וכמה שדות מידע אחרים.
Certificate נחתם בחתימה דיגיטלית, לפחות בעזרת המפתח הפרטי העצמי.
X.509 Certificate הוא תקן שמכיל כמה שדות סטנדרטיים ומאפשר הרחבה לשדות נוספים – ללא הגבלות מסוימות על אורך / מבנה המידע.
Certificates נקראים לעתים בקיצור certs, בעיקר בפורומים מקצועיים של אבטחה.

הנה דוגמה למבנה של Certificate:

מקור: וויקיפדיה

הערה: Certificates שמועברים ב HTTPS מקודדים לרוב בפורמט בינרי, ASN.1, כך שלא תראו אותם בפורמט של clear text, כמו זה למעלה.

Issuer זו הסמכות שאימתה את זהות השרת/משתמש, ה CA.
כל Certificate מגיע עם תאריך תפוגה – ולא יהיה תקין אם תאריך זה חלף.
אלו פרטי הישות שאותה ה Certificate מזהה. הרשומה החשובה ביותר היא ה CN (קיצור של Common Name, ע"פ פרומט X.501, כזה המוכר לכם אולי מ LDAP) שצריכה להתאים ל DNS Entry, במידה ומדובר בשרת.
זהו המפתח הציבורי של הישות המזוהה.
זוהי חתימה דיגיטלית שנוצרה על בסיס MD5 (פונקציית גיבוב) של כל ההודעה – ונחתמה ע"י המפתח הפרטי של ה CA (או חותם אחר: חתימה עצמית או ארגון). כדי לפתוח אותה המשתמש זקוק למפתח הציבורי של ה CA.

הנה הצורה בה ה Certificate מוצג בממשק המשתמש של "חלונות":

הערה: certificate זה לא מתואם עם הדוגמה מוויקיפדיה – הוא חדש הרבה יותר

מהיכן מגיעים Server Certificates למחשב?

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

ובכן, כל הדפדפנים המודרניים מגיעים בהתקנה עם רשימה של Certificates של ה CAs המרכזיים.

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

ניתן לצפות ב Certificate Store בעזרת הפעלה של certmgr.msc מה command line בחלונות.

Root CAs בד"כ חותמים דיגיטלית על עצמם – כלומר בעזרת ה public key שב Certificate ניתן לאמת את החתימה הדיגיטלית.

CAs משניים (Intermediate) חתומים ע"י Root CAs. זו היא בעצם שרשרת האמון עליה דיברנו בתחילת הפוסט.

נחזור לדוגמה שהצגנו מוקדם יותר:

במקרה זה Go Daddy Class 2 הוא ה Root CA שחתם על ה Certificate של עצמו וחתם על Go Daddy Secure – שזהו CA משני (אפילו ששייך לאותה החברה. אולי מדובר בסניף אחר או חטיבה אחרת, למשל).
Go Daddy Secure הוא זה שחתם לנו על buy2 ואימת את זהותו.

בכדי שהדפדפן יאשר את זהותו של buy2, לפחות Certificate אחד בשרשרת צריך להיות trusted (קרי נמצא ב Certs store שלנו), מאומת ותקין.
בהמשך הפוסט נראה מה קורה כאשר Certificate הוא לא תקין.

שרשרת האמון ב certificates. מקור: איליה גריגוריק

מעניין לציין של JVM של ג'אווה יש Certificate Store נפרד מזה של מערכת ההפעלה(המורכב מ2 חלקים הנראים truststore ו keystore). ייתכן ויש בו Certificates שונים מאשר בדפדפן. כלומר: אנו יכולים לאמת ישות דרך הדפדפן ולא בעזרת קוד ג'אווה – או להיפך.
אם אתם "חוטפים" שגיאות של javax.net.ssl.SSLException: untrusted server cert chain בעוד אין לבם בעיה להתחבר לאתר עם הדפדפן – יש סיכוי גבוה של JVM אין את ה certificates שיש לדפדפן.

נאמר לי שעורקל נתקלה בבעיה טכנית בגינה היא לא עדכנה certificates בגרסאות הג'אווה זמן מה – אולם לא ראיתי זאת בעצמי.

מהיכן מגיע Client Certificate למחשב?

Client Certificate הוא כזה שמזהה את המשתמש הספציפי, ומשמש לצורך Authentication למערכות שתמוכות בשיטה זו. מאיפה אם כן הוא מגיע למחשב שלכם? האם איי פעם נפגשתם עם סוכן של Go Daddy או VeriSign ונדרשתם להוכיח את זהותכם? – אני מניח שלא.

יש כמה דרכים לייצר Client Certificate:

דרך פשוטה אחת היא בעזרת תוכנה שעושה זאת, ואז אתם חותמים על ה Certificate בעצמכם. למשל הפעלה ב command line של:

openssl genrsa -des3 -out server.key 1024

תייצר מפתח פרטי בשם server.key ואז הפעלה של

openssl req -new -key server.key -out my_cert.csr

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

דרך אחרת היא שהשרת מייצר certificate עבורכם וחותם עליו. אתם מורידים קובץ ועושים לו import לתוך ה Certificate Store.

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

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

התנהגות הדפדפן וחיווי למשתמש

לא תמיד הכל הולך כמתוכנן ולפעמים אתר עובד עם HTTPS שנראה תקין… מלבד פרט אחד קטן. הדפדפנים מנסים לשקף למשתמש את מידת הסיכון ע"י חיווי מתאים בממשק המשתמש – חיווי שהם מנסים שיהיה אינטואיטיבי וברור גם למשתמש שלא מכיר את פרוטוקול TLS (קרי: כמעט כל המשתמשים).

עד כמה חיווים אלו ברורים? – תגידו אתם.

אני חושב כדאי להכיר אותם בתור משתמשים "מתקדמים" וגם כדי לענות ללקוח שנתקל בחיווי ופונה אליכם בשאלה "מה לא בסדר?"

לפני שהדפדפן שולח את client certificate לשרת – הוא מבקש את פרטי המשתמש בעזרת dialog (שעשוי להראות מעט שונה בין דפדפנים שונים):

חלון אישור לשליחת Client Certificate בכרום

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

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

Mixed Content

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

אציין שיש חריגים בכלל של Mixed Content: תגיות img, video, audio ו object שלא כולל data attributes – לא נכללים בבדיקה. מאוד קשה לבצע התקפה עם תמונה – ויש מעט אתרים שמארחים תמונות על גבי HTTPS.

כלומר: אם אנו בונים אתר HTTPS אנו צריכים לוודא שכל ה scripts, css ועוד מגיעים גם ממקורות המאובטחים ע"י HTTPS. זה לא תמיד טריוויאלי.

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

ההזהרה, כפי שנראית בעת כתיבת הפוסט בכרום

IE, ולפני כחודשיים בערך החלו גם כרום ו FF לחסום כהתנהגות ברירת-מחדל את תוכן ה HTTP כאשר יש mixed content. כלומר: הדף נטען ללא רכיבי ה HTTP – מה שיכול לגרום לו לרוץ בצורה לא טובה / לא לרוץ בכלל.

למשתמש יש אפשרות אפשרות לבחור שהוא רוצה בכל זאת לטעון את תוכן ה HTTP – מכיוון שהוא מבין את הסיכון ולוקח אותו עליו.

הנה הדרך בה מוצג תוכן חסום והדרך לאפשר אותו בכרום:

והנה ב FF:

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

Certificate לא תקין:

כאשר ה Certificate לא תקין, הדפדפן מציג זאת בצורה דיי בולטת:

בעצם, זה נראה דיי מפחיד – וזה יכול לקרות גם לאתר הבטוח שלכם. מספיק שללקוח שלכם אין Certificates מעודכנים של ה CA (כל מיני חברים שרצים על Win XP ו IE7) – וזה מה שהם יקבלו, גם אם האתר שלכם תקין לחלוטין. נדמה לי שפעם הדפדפן היה מגיב בצורה פחות אגרסיבית ל Certificate שהוא פג תוקף – אך זה לא המצב עכשיו.

הנה אתר בו תוכלו למצוא לינקים לדוגמה עם תקלות שונות ב Certificate שלהם: http://testssl.disig.sk/index.en.html

הנה שני אתרים שיכולים לעזור ולנתח מדוע יש תקלת Certificate:

סיכום

פו…. זו הייתה כתיבה ארוכה!
סקרנו את האופציה לבצע Authentication בעזרת HTTPS/TLS על בסיס Certificates וראינו בגדול כיצד המנגנון עובד.
נשארו עוד כמה נושאים שאני רוצה לדון בהם – על ההשלכות היותר קונקרטיות למפתח – אשמור חלק זה לפוסט המשך קצר.

שיהיה בהצלחה!

—-

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

HTTPS – חלק א': סקירה

HTTPS הוא HTTP עם SSL (קיצור של Secure Sockets Layer). ה "S" ב HTTP משמעה "Secure".

עד לפני מספר שנים, HTTPS היה פרוטוקול שהיה נפוץ בעיקר במערכות Enterprise, ו/או אתרים משעממים אחרים.
דברים השתנו, ויותר ויותר אתרים משתמשים ב HTTPS בתור פרוטוקול ברירת המחדל שלהן: גוגל, טוויטר, פייסבוק ועוד. ע"פ סקר SSL Pulse (לינק עם נתונים גרפיים), בשנה האחרונה אחוז האתרים שעובדים ב HTTPS עלה מ 15%, ל 52%! ייתכן והסקר מעט מוטה – אך בהחלט יש כאן מגמה.

ישנן כמה סיבות שבגללן השינוי מתרחש:

HTTPS הוא "תואם" ל HTTP ואינו דורש (בתיאוריה) שינויי קוד בכדי לעבור אליו.
החומרה נעשית חזקה יותר ויותר, והתקורה של עבודה ב HTTPS היא כבר לא-משמעותית*.
מודעות גדלה לפרטיות ואבטחה ברשת.
- לאחר חשיפת המעקב של NSA, קם ארגון האינטרנט והציע להצפין את כל התעבורה ברשת ב HTTPS.
- גוגל ועוד כמה חברות גדולות, החלו להחליף את מפתחות ההצפנה ה א-סימטריים של ה HTTPS שלהן מ 512 או 1024 ביט, ל 2048 ביט – כלומר: מפתחות חזקים בסדרי גודל [א].

* מלבד מקרה חשוב אחד – עליו נדבר בהמשך.

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

על שאלות אלו, ואחרות – אנסה לענות בפוסט זה.

Context: היכן פרוטוקול HTTPS "מתרחש"?

הבהרה / היסטוריה: פרוטוקול ה SSL (קיצור של Secure Sockets Layer) הוגדר ע"י חברת Netscape עבור הדפדפן Netscape Navigator – שאיננו קיים עוד. הוא היה בגרסאות 1.0 עד 3.0, ואז הוא הועבר לגוף תקינה סטנדרטי ושמו שונה ל TLS (קיצור של Transport Layer Security). בשנת 1999 שוחרר TLS גרסה 1.0, הגרסה העדכנית של TLS היא 1.2 (שוחררה בשנת 2008).
למרות שהשם "TLS" קיים כבר יותר מעשור, השם SSL דבק ועדיין מוכר יותר / משתמשים בו לעתים קרובות בהחלפה ל TLS. ישנו עוד ציוד רשת (בעיקר שרתים) שעדיין תומכים ב SSL או גרסאות ישנות של TLS – מה שמחייב את הדפדפנים לעבוד בגרסה ישנה יותר (ופחות מאובטחת) של הפרוטוקול.

בסך הכל, TLS הוא פרוטוקול שרץ מעל TCP ומתחת ל HTTP (או פרוטוקולים אחרים ברמת ה"אפליקציה"), כך שבעקרון הוא לא משנה את אופן העבודה של HTTP:

כדאי לציין שיש עוד פתרונות הצפנה ל HTTP כגון VPN או IPSec שהם ברמת פרוטוקול ה IP – אך הם מחוץ ל scope של דיון זה.

אלו שירותים פרוטוקול HTTPS מספק?

"הצפנה!" – נכון. אבל הצפנה של מה?

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

הצפנה של המידע העובר בין הלקוח לשרת – כדי שצד שלישי לא יוכל להאזין לתקשורת.
Authentication: זיהוי השרת ו (אולי גם) הלקוח – כדי שנדע, למשל, ש"הבנק" שלנו הוא באמת הבנק שלנו, ולא אתר מתחזה [ב].
וידוא שלמות ההודעה, בעזרת "חתימה דיגיטלית" – כדי להתמודד עם התקפות מסוג Man in the Middle.

פרוטוקול TLS בפעולה בדפדפן כרום:
ורוד – אני רואה שיש אימות שאני אכן מחובר לבנק הפועלים. לפני כל הכנסה של כרטיס אשראי – כדאי מאוד לוודא שהשרת מאומת ושמו נשמע הגיוני.
תכלת – הממ…. 112-ביט הוא מפתח מעט חלש בימנו + חיבור 1.0 TLS הוא מעט לא מעודכן וחשוף להתקפות כגון BEAST (בהמשך)

על מפתחות סימטריים וא-סימטריים (הצפנה)

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

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

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

לצורך כך הומצאו המפתחות הא-סימטריים. האלגוריתם הנחשב בתחום זה הוא אלגוריתם RSA (שאחד ממפתחיו הוא ישראלי) – אלגוריתם שמאפשר לסיטואציה המדהימה הבאה להתרחש:

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

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

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

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

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

האם פרוטוקול ה SSL/TLS הוא מוגן לחלוטין?

לא.

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

כרגע החוק בארה"ב (למיטב ידיעתי) מגביל את גודל המפתחות ל 256 ביט להצפנה סימטרית ול 2048 ביט להצפנה אי-סימטרית (במקרה שלנו: RSA).

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

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

יש גם באגים בפרוטוקול ה SSL עצמו.
התקפות מפורסמות אחרונות המבוססות על באגים אלו קרויות BEAST ו CRIME – וחלק גדול של משתמשי האינטרנט עדיין חשוף אליהן [ג]. חשוף, מכיוון ששרתי אינטרנט רבים הם לא מעודכנים ועדיין עובדים עם גרסאות ישנות של TLS או אפילו SSL (כלומר: גרסה ישנה הרבה יותר)
.
ע"פ שמועות, מומחי ה NSA "דחפו" באגים מתוחכמים לתוך התקן של TLS – כדי שהם יוכלו לנצל אותם בהמשך. יש פה הנחה, לא בהכרח נכונה, שהבאגים כ"כ מורכבים ופינתיים – שאף אחד לא ימצא אותם. ה NSA, בין היתר גם שילם ל RSA כדי שיחלישו את ההגנות שלהם.

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

מה בהמשך?

הפוסט מתארך ולכן אני מחלק אותו ל2 חלקים.

בחלק א' סקרנו את הפונקציונליות הכללית של HTTPS (קרי TLS/SSL) וקישרנו אותו ל TCP/IP Stack שכולנו מכירים.

בחלק ב' אנסה להתמקד ב HTTPS Authentication וה Certificates – צד חשוב מאוד בפרוטוקול ה HTTPS, ובהשפעה של HTTPS על מערכת / המתכנתים / Operations.

שיהיה בהצלחה!

—

לינקים:
מדוע השתנה שם הפרוטוקול מ SSL ל TLS?

—

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

[ב] שרתי DNS נחשבים כלא כ"כ מאובטחים, ולכן התקפה לא מורכבת כ"כ יכולה להפנות אותנו לאתר שונה ממה שהתכוונו אליו.

[ג] לא צריך מאוד לדאוג – כי אלו התקפות מורכבות למדי ליישום. עדיין הייתי רוצה שכל שירות דואר אלקטרוני או אתר שמתעסק בכסף שלי, יעבוד עם TLS גרסה 1.2.

על Federated Identity

האינטרנט פורח – וזה דבר נהדר. במקום אתרים סטטיים יש לנו עכשיו "אפליקציות" שעושות דברים נפלאים. לעתים הולכות וקרבות אפליקציות משתפות פעולה זו-עם-זו בכדי לעשות משהו נפלא חדש.
בכדי לעשות את כל הדברים הנפלאים הללו, בצורה שתתאים לנו, האפליקציות שומרות פרטים עלינו. פרטים אישיים. פרטים חשובים.בכדי להגן על הפרטים האישיים של המשתמשים, העולם משתמש במנגנוני-אבטחה, שאחד מיסודותיהם הוא מנגנון הAuthentication (זיהוי). כשמדברים על האינטרנט ואפליקציות המדברות זו-עם-זו, אנו מדברים לרוב על Authentication בעזרת Federated Identity (= זהות בקבוצה מבוזרת).

בפוסט זה נסקור את עקרונות הבסיס של פרוטוקולי Federated Identity ונספק כמה מילים על הפרוטוקולים הנפוצים.

זהות

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

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

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

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

זהות דיגיטלית, או זהות אינטרנט היא דומה – אך קצת שונה:

בעולם הדיגיטלי אין באופן טבעי מאפיינים ייחודיים (מראה, קול, או אפילו דרך הליכה) המזהים אדם שלישי – כולם נראים "אותו הדבר" מלבד כמה פרטים שהצהירו על עצמם.
- מעניין לציין שיש עיקרון שנקרא "risk-based authentication" בו מאמתים זהות של משתמש (ליתר דיוק: מחשבים סיכון לגניבת זהות) ע"י איסוף ופענוח "ההתנהגות הדיגיטלית" הטיפוסית של המשתמש, למשל: מספר השניות שהוא מבלה בכל דף באתר וסדר הדפים שהוא ניגש אליהם. אם תתחברו לאתר הבנק ותנהגו בצורה שונה מאוד מבד"כ – יש סיכוי שתחסמו ותתבקשו לגשת לסניף להוציא ססמה חדשה.
מיקום גאוגרפי הוא קל ל"זיוף": כיצד אני יודע שהבחורה הנחמדה מאשדוד שמופיעה בפייסבוק היא לא האקר רוסי שנמצא 2000 קילומטר משם?
קל למדי לפורץ "לאמץ" מספר זהויות דיגיטליות, אפילו באותו האתר – דבר הרבה יותר מסובך בעולם הפיסי.
כמות הישויות (חברות / אפליקציות) שאוספות עלינו מידע הוא רב יותר, והמידע מפורט יותר. קשה להאמין שביה"ס שלמדתם בו במשך שנים שמר מידע שווה ערך למה שאתר אינטרנט שומר עליכם בתוך מספר ימים של שימוש.
מספיק שרק אתר אחד ייפרץ – בכדי שפרטים אישיים כלשהם שלכם יהיו נגישים לאישיות לא רצויה.
אתרי אינטרנט יכולים לייצר בקלות יחסית חזות אמינה, או לפחות אנו נוהגים בפחות זהירות כלפיהם: לכמה אתרים נתתם את כתובת הדוא"ל שלכם והשתמשתם שם באותה הסיסמה כמו חשבון הדוא"ל? לכמה בתי עסק נתתם את הכתובת שלכם בבית, ומפתח?

Federated Identity

עקרונות ה FI אינם תקן או דרך-יחידה לבצע את הדברים, אולם אם נתבונן במנגנונים הנפוצים:

(Kerberos)
SAML 2.0
OAuth
OpenID
Claims-Based Authentication

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

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

תהליך אפשור גישה למשאב. אנו נתמקד בפוסט זה בשלב ה Verification

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

בשפה של FI מגדירים את המונחים הבאים:

Service Provider – את הישות נותנת את השירות, למשל שרת פייסבוק.
Identity Provider (בקיצור: IdP) – את הישות שמאמתת את זהות המשתמש (שלב Verification). ייתכן וה IdP הוא לא המערכת בה מנהלים את המשתמשים (קרי LDAP / Active Directory) אלא שירות חיצוני שנמצא ביחסי אמון עם ה User Repository.
Credential Store (לחלופין Authentication Store) – היכן ששומרים את ההרשאות מה משתמש מורשה לעשות (שלב ה Permission Check), לרוב זהו נותן השירות (למשל: פייסבוק), אך תאורטית זו יכולה להיות מערכת צד-שלישי שנותן השרות סומך עליה. פיזית, נתונים אלו נשמרים לרוב ב Directory Service או בסיס-נתונים.

בדומה לעולם הפיסי, המפתח לFI הוא אמון (Trust) בין השרתים השונים. אמון זה נוצר פעמים רבות תוך כדי החלפת מפתחות-הצפנה בין 2 השרתים. ברגע שיש אמון, האמון הוא "מוחלט"[א]: אין וידוא נוסף מעברת לאימות זהות השרת עליו סומכים (על בסיס הצפנה) ווידוא שמה שנשלח מהשרת המרוחק לא שונה (modified) בדרך.

הנה תרשים שמתאר בקירוב את האופן בו פרוטוקולים של FI עובדים:

תרשים A

הנחה מקדימה: ה SP מכיר וסומך על ה IdP (נעשה בעזרת קונפיגורציה ידנית).

המשתמש פותח דף בדפדפן ומנווט ל SP.
ה SP לא מזהה את המשתמש ומפנה אותו ל IdP. אופן ההפניה שונה מפרוטוקול לפרוטוקול, וכן זהות ה IdP.
ה IdP מאמת את זהות המשתמש בדרכים שעומדות לפניו: הוא מכיר את המשתמש וצריך להיות מסוגל לאמת אותו.
ה IdP מפנה את הדפדפן חזרה לדף המקור (פרטים הופיעו בבקשת האימות, בד"כ) ומייצר "מסמך" (token או ticket) המתאר פרטים שהוא יודע על המשתמש: id, מיקום, קבוצות שהוא שייך אליהן וכו'. פרטים אלו נקראים לרוב Assertions או Claims וה"מסמך" שמכיל אותם הוא מין וריאציה דיגיטלית של דרכון או ת"ז.
ה"מסמך" נחתם ב חתימה דיגיטלית כדי לוודא שצד שלישי לא יוכל לעשות בו שינויים.
ה SP מקבל את המסמך – הוא מאמת, לרוב בעזרת החתימה הדיגיטלית, את זהות ה IdP ואת שלמות/תקינות (integrity) המסמך.
במידה והמסמך נמצא תקין, הוא מבצע log in למשתמש ע"פ הפרטים שבמסמך, כלומר: בד"כ יוצר session שמתאר את המשתמש.

בסיכום מהיר ניתן לציין ל FI את היתרונות והחסרונות הבאים:

יתרונות

משתמש: כאשר משתמשים באותה סיסמה על ריבוי מערכות, ברגע שמערכת אחת נפרצת הפורץ יכול לנסות את הסיסמה ב 100 האתרים הנפוצים – אולי יתמזל מזלו. בעזרת FI אין צורך לנהל מספר-רב של ססמאות: אם מערכת (Service Provider) נפרצה – אין עליה את הסיסמה שלי.
משתמש: חוויית משתמש טובה. מעבר לכמה שניות המתנה בזמן ה login, המשתמש לא מודע ש FI היה בכלל מעורב.
מפתח ה SP: לא צריך להתעסק עם הנושא המורכב שקרוי Authentication. אנשי שיווק היו כבר ממציאים: "Authentication as a Service".
מפתח, Admin ומשתמש: היכולת לספק (SSO (Single Sign-On בצורה אלגנטית (למשל: פרוטוקול SAML 2.0), הרבה יותר אלגנטיים ממשפחה נפוצה אחרת של פתרונות SSO שנקראת "Credential Storage" בה שרתים שונים / מכונת המשתמש שומרת שם וסיסמה לשרתים השונים. SSO הוא טוב כי:
1. המשתמש – לא צריך לזכור הרבה ססמאות / לבצע Login שוב כאשר הוא מופנה למערכת אחרת.
2. ה Administrator – לא צריך לנהל מנגנוני Authentication כפולים
3. המפתח (של SP) – חוסך לעצמו התעסקות עם Authentication. שהמפתח של ה IdP – יעשה את זה!
מפתח SP: מקבל אינטגרציה קלה בין מערכות, שכעת רק צריכות להסכים על פרוטוקול ה FI.
מפתח, Admin: מנגנוני FI לרוב גמישים למדי, ומאפשרים ל IdP לספק כל סט של נתונים שהאפליקציה דורשת, למשל: מקום גאוגרפי של המשתמש, שפה מועדפת וכו'. זהו תחליף חלקי לשמירת מידע personalized על המשתמש, ויותר מזה – ניהול כפול שלו במספר מערכות (אני רוצה לכוון את השפה עברית במערכת אחת ולא בעשרה).

חסרונות

החשש שפריצה ל IdP תספק לפורץ גישה לכל האפליקציות של המשתמש/ים על ה IdP, מה שנקרא "מפתח יחיד לממלכה".
הסיכון קיים, אבל מכיוון שניהול של 20 ססמאות מוביל לרוב לסיסמה אחת על 20 שרתים שפחות מאובטחים מה IdP הממוצע – אין אלטרנטיבה טובה יותר לסיכון הזה, עדיין.
פתרון מורכב להקמה. למרות שהרעיון אינו חדש, יש מחסור בבסיס ידע / חומר כתוב [ב] / מומחים בתחום ה FI, במיוחד כאשר מדובר בdeployments שאינם בסיסיים. לאחרונה צצים פתרונות של "IdP as a Service" (לדוגמה Azure ACS) – לא אתפלא לגלות שהם מצליחים לפשט רבות את מלאכת ההגדרה.
אין סטנדרט יחיד ל FI (בעצם יש 3-4 נפוצים), מה שמחייב מערכות לתמוך בכמה תקנים / לא לתמוך ב FI עבור כל המשתמשים.

הפרוטוקולים

כמה מילים על ההבדלים בין הפרוטוקולים הנפוצים:

OpenID
מקצר / מפשט את תהליך ה Trust בין ה SP ל IdP. בעזרת OpenID, אתר (SP) יכול לסמוך על IdP מבלי שה IdP יכיר אותו. כלומר: אין צורך בהחלפת מפתחות / certificates. מתאים לאתרי אינטרנט שפתוחים לכולם, ושבעיקר רוצים לזהות את המשתמש מבלי להכביד עליו. לרוב חיבור של OpenID נראה למשתמש הקצה ככפתור "התחבר באמצעות… "
IdPs של OpenID כוללים את: Facebook, Google, Yahoo ועוד.

OpenId מאפשר שתי דרכים שונות לבצע Authentication:

המשתמש נרשם ל IdP ומקבל OpenId. כשהוא מתחבר ל SP עליו להזין את ה OpenId שבתוכו מקודד URL ל IdP וכך ה SP יודע להיכן להפנות את הדפדפן לצורך Authentication (שלב 2 בתרשים A)
(כנראה יותר נפוצה) כשהמשתמש ניגש ל SP, ניתן לו ב UI מבחר של IdP והוא בוחר אחד מבניהם אליו ה SP יפנה את הדפדפן לביצוע תהליך ה Authentication.

OAuth

הייחוד ב OAuth הוא שהוא כולל גם Authorization, Authorization שעושה משתמש הקצה לאתר מסוים – לגשת לפרטים שלו (קריאה ו/או כתיבה).
נגדיר את "אתר המקור", כאתר שמנהל פרטים אישיים של המשתמש ואתר ה Service Provider כנותן שירות מסוים נוסף.
התצוגה למשתמש הקצה תהיה הפנייה לאתר המקור ושאלה: "אתר SP מבקש לגשת ל… שלך, האם אתה מאשר?" האישור הוא כן/לא, לעתים עם יכולת לאשר רק חלק מהפעולות. לעתים השאלה מופיעה בתוך iFrame (יכולת שנחסמה בגרסה 2.0 של הפרוטוקול) בכדי לא לגרום למשתמש לאבד אוריינטציה (אבל מאפשר התקפות clickjacking).

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

SAML
פרוטוקול SAML (בעצם SAML 2.0, אף אחד לא משתמש בגרסה 1 בימנו…) הוא פרוטוקול FI "קלאסי".
על ה IdP וה SP לייצר trust ע"י החלפת מפתחות ומשתמש בעיקר תסריטים של Enterprise בהם חשוב להגביל גישה ל SP ממשתמשים לא רצויים. SAML 2.0 גם תומך ב SSO.
SAML, כדרך אגב, מתבסס על XML/SOAP (טכנולוגיות כמעט "מוקצות" בימנו) כבסיס.

שיהיה בהצלחה!

—

[א] בניגוד לעולם האמיתי בו יש לנו דרגות של ספק, גם באלו שאנו "מאמינים".

[ב] דוגמה פשוטה: התיעוד הכי מקיף שמצאתי לאחר חיפוש על SAML 2.0 (פרוטוקול נפוץ מאוד, במיוחד בעולם ה Enterprise) – הוא וויקיפדיה.

—

קישורים:

מיתוסים והבהרות לגבי SAML (מ 2003)