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 שכתובתו 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, כמו זה למעלה.

1. Issuer זו הסמכות שאימתה את זהות השרת/משתמש, ה CA.
2. כל Certificate מגיע עם תאריך תפוגה - ולא יהיה תקין אם תאריך זה חלף.
3. אלו פרטי הישות שאותה ה Certificate מזהה. הרשומה החשובה ביותר היא ה CN (קיצור של Common Name, ע"פ פרומט X.501, כזה המוכר לכם אולי מ LDAP) שצריכה להתאים ל DNS Entry, במידה ומדובר בשרת.
4. זהו המפתח הציבורי של הישות המזוהה.
5. זוהי חתימה דיגיטלית שנוצרה על בסיס 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:

• https://www.ssllabs.com/ssltest/analyze.html
• http://www.sslshopper.com/ssl-checker.html

סיכום

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


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

----

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

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

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

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

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

1. HTTPS הוא "תואם" ל HTTP ואינו דורש (בתיאוריה) שינויי קוד בכדי לעבור אליו.
2. החומרה נעשית חזקה יותר ויותר, והתקורה של עבודה ב HTTPS היא כבר לא-משמעותית*.
3. מודעות גדלה לפרטיות ואבטחה ברשת.
• לאחר חשיפת המעקב של 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.

מצגות מכנס Expert Days 2013

בכנס Expert Days 2013 העברתי סמינר (יום שלם) על "יסודות לפיתוח קוד צד-לקוח" (אפליקציות ווב), הנה המצגות:


Networking Crash Course

HTTP: the protocol of the web

Get to know the browser and write Faster web applications

Security: Same Origin Policy

Lost in translation

אנקדוטה קטנה על הדרך:

גייקטיים, פירסמו פוסט ישן שלי באתר - תראו איך תורגמה הכותרת:

ליאור

Bootstrap: תבניות עיצוב לווב

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

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

בכלל, ברירת המחדל של HTML איננה ממש אסתטית: טקסט שחור על רקע לבן עם מרווחים לא הגיוניים וללא צבע, הפקדים נראים כמו פקדים בסיסיים של מערכת ההפעלה... - זו לא התחלה טובה לאתר "החלומות" שלנו.
האם HTML5 boilerplate ישפר את המצב? Plug-Ins של jQuery לאפקטים הם הדרך? לא, לא, ולא.

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

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

על Bootstrap

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

• Layout מסוים של הדף.
• Navigation Menu - המאפשר לעבור מדף לדף באתר.
• Side Bar - אם מידע שימושי שאינו משתנה, או משתנה מעט ע"פ התוכן המוצג במרכז הדף
• וכו'.

הנה 3 אתרים לדוגמה שמציגים את תבניות הללו (לחצו על התמונות כדי להגדיל):

 

יש עוד כמה תבניות נפוצות אחרות, למשל כמו grid (קרוי גם: cards):

Bootstrap מנסה לתת התחלה של עיצוב אלגנטי לאתר. רק מעצם ההוספה של ספריית bootstrap לדף HTML פשוט - הוא כבר נראה קצת טוב יותר:

טקסט HTML פשוט, בלי ועם Bootstrap שנטענה.
וידוי: הוספתי על אלמנט ה body תכונת class עם הערך container, בכדי לקבל את המרכוז.

Responsive Web Design

משפחה חשובה נוספת של תבניות עיצוב-אתרים שהופכת לפופולרית בשנים האחרונות היא משפחת התבניות של Responsive Web Design (בקיצור RWD): כיצד מתאימים אתר למחשב שולחני, טאבלט וסמארפון - מבלי לכתוב את האתר 2 או 3 פעמים (= תוספת עלות משמעותית לפיתוח!)

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

למרות הבאזז הרב מסביב ל"תחכום" שב RWD, ניתן למצוא מספר של תבניות פתרונות עיצוב שחוזרים על עצמם:

• "קיפול" תפריטים (toolbar) ל drop-down menu
• צמצום מספר עמודות של desktop/tablet ל "מחסנית" (stack) - בסמארטפון
• תמונות ברזולוציות שונות למכשירים שונים
• התמודדות עם touch events
• וכו'

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

גישה נפוצה היא מה שנקרא "גישה מצמצמת" (subtractive approach) בה כדי שאתר יתאים ל Smartphone, למשל, מוסיפים לקוד ה Desktop קטעי קוד ש"יבטלו" פונקציונליות מסוימת / פחות חשובה שאין לה מקום במסך ה Smartphone.
המשמעות היא שכל הקוד של ה Desktop ירוץ על המכשיר הכי חלש (סמארטפון [ב]), ויש פה חוסר יעילות משמעותית.

הגישה העדיפה בד"כ היא מה שנקרא Progressive Enhancement (חלק מ"Mobile First") - לטעון את הבסיס למכשיר הסמארטפון, ולטעון עוד קוד / קבצים למכשירים ה"חזקים" יותר - קוד שמוסיף את הפונקציונליות הנוספת של המכשירים הללו.

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


הערה: במרכז Bootstrap גרסה 3 (החדשה, יחסית) עמד הנושא של Responsive Design ו Mobile First (בגלל ההבנה שזה שמובייל הופך להיות מרכז השוק). Bootstrap 3 הציגה שינויים לא תואמים-לאחור ל Bootstrap 2, ורבות מהתכונות / פתרונות שאתאר בפוסט זה, המתבסס על Bootstrap 3, לא יהיו נכונים / מדויקים לגרסאות ישנות יותר.

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

עיצוב ברירת-המחדל של Bootstrap

כמה נקודות מעניינות על Bootstrap

• Bootstrap פותחה בחברת Twitter על להתמודדות עם חוסר-קונסיסטנטיות של ה UI שפותח במחלקות שונות בחברה. עובדים בחברות גדולות בוודאי מכירים את האתגר.
• Bootstrap שוחררה כ Open Source באוגוסט 2011.
• כבר בפברואר 2012 (!!!) היא הפכה להיות הספריה הפופולרית ביותר ב Github. סקר הראה שכ 1% מאתרי האינטרנט בעולם בנויים בעזרת Bootstrap (רוב אתרי האינטרנט נבנו לפני ש Bootstrap בכלל הופיעה).
• Bootstrap מתבססת בעיקר על CSS ורק מעט JavaScript - הדבר מתאפשר בעקבות היכולות המקדמות של CSS3. כשיצאה - זו הייתה גישה חדשנית ביותר, היום ניתן למצוא משחק מחשב (פשוט למדי, שלא לומר מעאפן) שכתוב ב CSS ללא ג'אווהסקריפט.
• Bootstrap מתבססת על LESS (בזמן "קומפילציה"), בניגוד למתחרתה החשובה Foundation שמבוסס על SASS.
• Bootstrap נפוצה בעיקר בקרב אתרים קטנים, בהם מנסים לחסוך בעלויות פיתוח האתר, אך עדיין ניתן למצוא לא מעט אתרים "בעלי תקציב" המשתמשים ב Bootstrap, למשל: AngularJs, viber.com, SugarSync או האתר של Fender (לחובבי הגיטרות).
• טיעון נפוץ נגד Bootstrap הוא: "אתם לא רוצים שהאתר שלכם יראה כמו כולם".
• מקור המונח "Bootstrap" הוא מאגדה גרמנית על הברון מינכהאוזן, שהצליח על פי האגדה לחלץ את עצמו מביצה טובענית על ידי משיכה בשערו שלו. בגרסה מאוחרת יותר מסופר כי השתמש באוזן הנעל (באנגלית: Boot strap) כדי לחלץ עצמו מים גואה. בתרגום לעברית ניתן לומר ש Bootstrap הוא "אתחול" - לרוב תהליך שאחראי לאתחל את כל התוכנה. בהקבלה, ספריית Bootstrap מספקת התחלה קלה / מהירה יותר לפיתוח אתרי ווב שנראים טוב.
• Bootstrap היא מודולרית: ניתן לבחור באלו חלקים אתם משתמשים וליצור custom build קטן יותר מהספרייה המלאה. בנוסף, תוכלו להגדיר ערכים לפרמטרים (צבעים, פונטים, גדלים וכו') שאתם רוצים לשנות, והם "יקומפלו" (בעזרת LESS compiler) לתוך העותק הפרטי שלכם של bootstrap.
• Bootstrap כוללת סט אייקונים מתאימה (חשוב למי שאין לו מעצב גרפי צמוד).
• אפשר למצוא כמה אינטגרציות ל Bootstrap עם ספריות UI אחרות, למשל jQuery Bootstrap או Bootstrap Angular directives (עדיין לא עודכן לתמוך בגרסה 3).

ה Grid-System

בוטסטראפ לא המציאה את ה Grid System, אך יש לה Grid System בוגר, responsive ושבשימוש ניכר - אז כנראה שניתן ללמוד ממנו משהו.

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

למה בעצם לא לעבוד באחוזים? גם הם סוג של "responsive"?

• מסך צר יחסית כדאי למלא, אבל על מסך רחב מאוד, לפעמים אתר נראה טוב יותר עם שוליים בצדדים. כלומר במסכים גדולים בוטסארטפ יוצרת ריווח בצדדים ומחלקת רק חלק מהמסך ל 12 עמודות.
• כאשר עובדים עם עמודות - קל יותר לקבוע ריווחים (margin) קבועים בין העמודות. עם אחוזים לא מקבלים את האפקט הזה.
• 12 כמספר חלוקה הוא "מספר קסם" עיצובי: הוא מתחלק ב 2, 3 ו 4 - מה שמאפשר חלוקה הרמונית של אלמנטים בין דפים שונים. היכולת להגדיר אלמנט בדף אחד כ 50% ובדף שני כ 55% - הוא לא "בריא" עיצובית.
• 12 הוא מספר קטן מספיק כדי שהיה קל למתכנת לעשות חישובים בראש. "6 זה חצי, 5 זה כמעט חצי". לרוב מקובל לעבוד עם מערכות צרות (12 או 16) או רחבות (960 או 976) - המדמות עמודה ל"בערך פיקסל, תלוי במסך" - מערכות שלמפתח יהיה קל לעבוד איתן.

ה grid system הוא fluid, כך שאם "טעינו" בחישוב, או אולי זה חישוב דינאמי בעת ריצה, ואלמנט חורג מ 12 העמודות - הוא "קופץ" לשורה הבאה, מה שנקרא Wrapping.

ניתן ליצור nesting של grid בתוך grid. אלמנט ברוחב 4 עמודות (שליש) בתוך אלמנט ברוחב 4 עמודות יצור אלמנט ברוחב תשיעית מרוחב התוכן במסך.

כפי שאמרנו, בוטסטראפ מגדירה שיטה לכתיבת אתרים responsive. עד גרסה 3 מערכת ה grid הייתה תקפה לכל מכשיר ורוחב מסך. זה עבד לפעמים יותר טוב - ולפעמים פחות טוב. בוטסטארפ 3 מגדירה 4 מערכות grid ל 4 גדלים של מכשירים:

• lg, למסכים ברוחב 1200 פיקסלים או יותר (מכוון למחשב שולחני או laptop)
• md, למסכים של 992 עד 1200 פיקסלים (מכוון לטאבלט בהעמדת landscape)
• sm, למסכים של 768 עד 992 פיקסלים (מכוון לטאבלט בהעמדת portrait)
• xs, למסכים קטנים יותר (מכוון לסמארטפונים)

מאיפה נבחרו המספרים? מהניסיון של טוויטר. אתם יכולים לשנות אותם.

ארבעת מערכות הגריד מאפשרות לבצע התאמות למכשירים מסוימים. למשל: לומר לאלמנט "אתה ברוחב 6 ב lg, אבל ברוחב 12 ב sm" - זאת על מנת לעשות התאמה קלה למכשירים אחרים.

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

איך קובעים רוחב של אלמנט? פשוט מוסיפים לו class של CSS בשם col-xx-yy, כאשר xx הוא lg עד xs ו yy הוא מספר מ 1 עד 12. למשל: col-sm-3 או col-md-9.

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

<div class="row"> <img ... class="col-lg-2"><p ... class="col-lg-3"></div>

כלי נוסף ב grid system הוא היכולת ליצור ריווח בעזרת offset. למשל:

<div class="col-md-4 col-md-offset-4">

יציב אלמנט ברוחב 4 ובמרחק 4 מהאלמנט הקודם באותה השורה.

בואו נראה דוגמה לעיצוב של אתר ע"פ מערכת 12 העמודות:

פרמטר אחרון מעניין הוא הצמד visible ו hidden. אם אלמנט מסוים פשוט לא מתאים לסוג רזולוציה מסוים, נניח לסמארטפון, אפשר להעלים אותו ע"י הוספת class בשם "hidden-xs". הפרמטר visible יגרום לאלמנט לא להופיע בכל הרזולוציות שלא צוין, לדוגמה "visible-md" יציג את האלמנט רק בטאבלט בהעמדת landscape.

Components

לבוטסטראפ כולל סט של פקדים סטנדרטיים שאפשר להשתמש בהם ללא כתיבת ג'אווהסקריפט.
כיצד? ע"י annotations של CSS, כמובן!

בואו נראה כמה פקדים נפוצים:

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

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

הנה כפתורים:

או טבלאות מעוצבות:

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

זהו!
אני מרגיש שמיציתי את ההעתקה של התיעוד הרשמי של bootstrap. אם אתם רוצים לקרוא עוד בנושא - פשוט לכו לשם.

Plug-ins

אינני רוצה לחזור על תיעוד רשמי מצוין, אז אקצר בפסקה אחת את נושא ה Plug-Ins.

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

ב Bootstrap אלו נקראים Plugins (כי הם בעצם jQuery plugins, אם משתמשים בהם יש לטעון את jQuery לפני bootstrap.js) ומגיעים 13 כאלו עם ספריית ה bootstrap כדי ליצור כפתורים דינמיים, tooltips, טאבים, dialogs וכו'. כשג'אווהסקריפט מעורב, לרוב יש שימוש ב attributes בצורה *-data ולא רק עוד classes על האלמנט.

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

תיעוד ה plug-ins נמצא כאן.

סיכום

הכרנו את Bootstrap, ספרייה סופר-פופולרית שברגע שמתרגלים לעבודה בה - ניתן לפתח בעזרתה אתרים שנראים טוב, ובמהירות. יש ל Bootstrap לא-מעט Controls ויכולות, אבל כמובן שהיא מוגבלת לסוג מסוים של עיצובים. אל תפחדו להוסיף עליה CSS Styles ו Controls חיצוניים בכדי להעשיר את החוויה - זה מה שהרבה משתמשים שלה עושים. האתרים הגדולים יותר ("בעלי התקציב") לרוב לא בוחלים באמצעים ומשתמשים בספריות מורכבות יותר, המאפשרות גם גמישויות רבות יותר. כרגע, Bootstrap פופולארית בעיקר בקרב אתרים קטנים, אך גם שמעתי פרשנות שהיא עשוייה לפרוץ את הגבולות הללו ולתפוס את מקומה של jQuery Mobile בתור ספרייה מובילה לפיתוח אפליקציות ווב למובייל בזכות היכולות הרספונסיביות שלה (הגריד ועוד כמה שלא כיסיתי בפוסט) והמשקל הקל שלה.

גם אם אתם לא מתכוונים להשתמש ב Bootstrap, שווה לשים בצד כ Reference את הרעיונות העיצובים שלה - רעיונות בהחלט חדשניים שאתם יכולים לקחת למערכת הווב שלכם.

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

---

לינקים מעניינים נוספים:

"למה Bootstrap היא ממש חשובה":
https://medium.com/what-i-learned-building/99fdd6e46586

סיכום ודוגמאות של שימוש ב Bootstrap:
http://www.designyourway.net/drb/the-popular-twitter-bootstrap-opinions-and-usage-inspiration/

רשימת שאלות ב Quora על Bootstrap:
http://www.quora.com/search?q=twitter+bootstrap

רשימה של כמעט מיליון (כלומר 319) אתרים שעוסקים ב Bootstrap:
http://bootstraphero.com/the-big-badass-list-of-twitter-bootstrap-resources

----

[א] מופע נוסף של הבעיה ניתן לראות באתרים כמו Wix.
Wix מספקים עורך WYSIWYG קל מאוד לשימוש לעריכת אתרי HTML. בכל זאת, זה לא מספק - כי למרות הכלים הנוחים, האתרים לא יוצאים יפים מספיק.
Wix תוקפים את הבעיה בעזרת יצירת המון templates מעוצבים מוכנים מראש שהמשתמש רק עורך בהם התאמות קלות. פתרון אחר: שוק של מעצבים שזמין לעזור למשתמשים (בתשלום, כמובן).

[ב] למרות שטאבלטים מצויידים כיום באותם מעבדים של הסמארטפונים, לעתים יש להם תדר שעון גבוה יותר (לדוגמה iPad Air ו iPhone 5S, כנראה בגלל הסוללה הגדולה יותר בטאבלט) ו bus רחב יותר של זכרון (כנראה בכלל ה GPU והצורך לצייר על מרחב גדול יותר), שמשפר את כלל ביצועי המכשיר.

ספר חדש בעברית: Code Complete

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

200 ש"ח?!
הסטודנטים בקורס התקוממו על המחיר המופרז: "2 שקל לעמוד? לא הגזמנו? יש ספרים של מאות עמודים במחיר 40 שקלים!"

המרצה, משום מה, לא התרגש וענה כך: "תחשבו שקניתם ספר של 1000 עמודים ב 100 ש"ח, פייר?"
"ואז מישהו סיכם אותו וצמצם לכם ל 880 עמודים לא-כל-כך חשובים שלא תצטרכו להשקיע מזמנכם ולקרוא, לא שווה 100 שקל?"

"ספר קצר הוא רב-ערך יותר מספר ארוך, ולכן שווה יותר."

על הספר

לאחרונה פורסם תרגום עברי לספר קלאסי בהנדסת תוכנה: Code Complete של סטיב מק'וול. זהו ספר חשוב, לא פחות מ The Pragmatic Programmer ו Clean Code - אם כי הוא זכה לפחות פרסום.

הזכרתי את הספר בפוסט קוד ספרותי = סופן של ההערות בקוד?

מהו אם כן ספר על "הנדסת תוכנה" - אתם בוודאי שואלים? האם זה לא "ספר תכנות"?

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

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

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

התרגום העברי

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

אני מאמין שאשר אכן עשה את מלאכת התרגום מתוך אידיאלוגיה ולא מתוך מניע כלכלי. כפי שסיפר ג'ף אסטווד (כותב הבלוג הפופולרי Coding Horrors): עריכת ספר המבוסס על פוסטים שלו בבלוג היה אחד הדברים הפחות מתגמלים (כלכלית) שעשה. ובקהל קטן כמו ארץ ישראל - הדבר נכון כנראה אפילו יותר.

מחיר הספר הוא 139 ש"ח, אם כי בעת כתיבת הפוסט הוא נמכר ב 111 ש"ח בהוצאת אופוס.

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

כיצד עומד הספר במבחן הזמן?

הספר Code Complete הוא איננו עתיק, אך גם איננו ממש חדש. הגרסה המעודכנת שלו (השנייה) פורסמה בשנת 2004.
יצא לי לקרוא חלקים (הנה והנה) מהתרגום העברי - ונהניתי!

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

הפרקים שהתיישנו (איסוף דרישות, כלי פיתוח, debug, בדיקות ו re-factoring) - לא נכללו במהדורה העברית, וטוב שכך.
הפרק המסכם את "הקוד הספרותי" ("Self-Documenting Code"), גם הוא לא נכלל לצערי, אך בעצם כל הספר מוליך לשם, שלב אחר שלב - ואת הסיכום תוכלו לקרוא בפוסט שלי שציינתי למעלה.

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


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


גילוי נאות: קיבלתי מאשר, ללא-תשלום, עותק של הספר.

על 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 (נעשה בעזרת קונפיגורציה ידנית).

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

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

יתרונות

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

חסרונות

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

הפרוטוקולים

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

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

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

1. המשתמש נרשם ל IdP ומקבל OpenId. כשהוא מתחבר ל SP עליו להזין את ה OpenId שבתוכו מקודד URL ל IdP וכך ה SP יודע להיכן להפנות את הדפדפן לצורך Authentication (שלב 2 בתרשים A)
2. (כנראה יותר נפוצה) כשהמשתמש ניגש ל 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)

סדנת פיתוח ווב ב Expert Days 2013

עוד כחודש, אעביר סדנה של יום (6 שעות) תחת הכותרת:

Client-Side Development Fundamentals in-Depth

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

• קורס מזורז ברשתות - עבור פיתוח ווב
• אדבר בקצרה על פרוטוקולים: הבדלים בין Ethernet ו 3G, על TCP/IP ו DNS.
• אדבר על רכיבי רשת וכיצד (בקצרה) הם עובדים: Proxy, Reverse Proxy, CDN, Load Balancer וכו'.
• סקירה יסודית של HTTP
• מחזור בקשה-תשובה, ומבנה הבקשה / התשובה.
• Methods/Verbs ו Status Codes מרכזיים - וכיצד להשתמש בהם כדי לכתוב שירותי REST בצורה נכונה.
• Headers חשובים שכדאי להכיר.
• Caching ו Cookies.
• מבנה הדפדפן וביצועים של אפליקציות ווב
• כיצד ניתן לנצל בצורה טובה יותר את הרשת בכדי לכתוב אפליקציות ווב מהירות יותר.
• כיצד להשתלב בצורה חכמה יותר עם pipeline הרינדור של הדפדפן.
• אבטחה וה Same-Origin Policy
• כיצד לתקשר עם domains אחרים, ולעשות זאת בצורה מאובטחת.

כל הדברים שהייתם מצפים ללמוד באוניברסיטה, אבל ללא 10 שנות האיחור ; )

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

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

הסדנא תתקיים ביום ראשון, ה 8 בדצמבר 2013, בכפר המכבייה (רמת גן).

• הנה רשימה של שאר הסדנאות בכנס
• הנה אתר הכנס

תודה,
ליאור

Enterprise Architecture: Authorization

קשה להגדיר מהי Enterprise Architecture, לרוב זוהי ארכיטקטורה של / ועבור ארגונים גדולים.

אחד מנושאי-הליבה שחוזר על עצמו ב Enterprise Architecture הם נושאי ה Authentication ו Authorization (בקיצור: A&A):

• Authentication - אימות הזהות של משתמש ("האם הוא מי שהוא טוען שהוא?")
• Authorization - כיצד שולטים בהרשאות מה המשתמש, לאחר שאימתנו את זהותו, יכול לעשות.

ישנם מעט Enterprise שלא כוללים A&A, למשל כמעט כל הגישות בווב יהיו על גבי HTTPS (הדורשת הזדהות) ולא HTTP.

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

בפוסט זה אני רוצה להתמקד בתחום ה Authorization ולהציג עקרון מעניין, שאני מניח שלא מוכר בקרב רבים, הנקרא Role-Based Authorization (בקיצור: RBA, נקרא גם Role-Based Access Control קרי RBAC).

הקדמה: המודל הנאיבי

ניהול המשתמשים הפשוט (והנאיבי) ביותר כולל טבלה בבסיס הנתונים של המשתמשים וססמותיהם. כשהמשתמש מתחבר למערכת עליו להקליד שם משתמש (כלומר: user id) וסיסמה ואז משווים את הפרטים למידע בטבלה. אם המידע נכון - שומרים את זהות המשתמש על ה session (באם זה server-side session, cookie וכו').
כמובן שכדאי שהססמאות יהיו "מגובבות" (hashed) ואולי גם "מטושטשות" (מה שנקרא salted [א]). נושא זה הוא תחום ה Authentication, אימות זהות המשתמש, נושא שאנני מתכוון לעסוק בו בפוסט זה.

עבור ה authorization, ניהול ההרשאות של כל משתמש, יוצרים טבלה נוספת "הרשאות" הכוללת user id, resource id, permission type (להזכיר: מימוש נאיבי לחלוטין). כל פעם שמשתמש ייגש למשאב, נבדוק בטבלה אם יש לו הרשאה לפעולה (למשל: read, write וכו') ואז נאפשר לו / נמנע ממנו את הפעולה.

ניתן לתאר את המודל הנאיבי באופן הבא:

מודל נאבי זה אינו scalable לניהול כאשר יש הרבה מאוד אובייקטים ו/או משתמשים. כדי שמודל Authorization "יעבוד כראוי" חשוב מאוד שיהיה נהיל (maintainable) ופשוט. מבחן בסיסי הוא לענות על שתי שאלות:

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

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

עוד בעיה של המודל הוא software scalability. הטבלה בבסיס הנתונים עלולה לצמוח במהירות. למשל: חשבו על שרת קבצים המאכסן כמיליון קבצים עבור כמה מאות משתמשים (תסריט סביר של חברה בינונית). אם עבור כל גישה לכל אובייקט נצטרך לסרוק טבלה של מיליוני שורות (אובייקטים x משתמשים) - אנחנו בבעיה.

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

1. משתמש א' מנסה להגדיר הרשאות למשתמש ב' - אך לא מצליח לעשות זאת. אחרי כמה ניסיונות הוא נשבר, בוחר את הקבוצה "Everyone" ומסמן כל checkbox שהוא רואה ב UI בכדי לאפשר למשתמש ב' את הגישה המיוחלת.
   התוצאה: המידע חשוף לכולם ואיננו מאובטח.
2. מנהל האבטחה / איש IT שאחראי על ההרשאות לא מצליח לעקוב למי יש גישה למה. עובדים עוברים תפקידים, עוזבים, מידע נוסף - אבל אין יכולת לעקוב אחרי מה שמתרחש. אין יכולת לאכוף חוקים אבטחה ארגוניים. מערכת האבטחה מסתמכת בעיקר על עובדים ללא הבנה בענייני אבטחה, שאבטחה היא בעיקר מעצור בשבילם "to get the job done".
   התוצאה: חוסר שליטה. לעתים מוסיפים מערכת אבטחה חיצונית שמגבילה את צעדי המשתמשים באופן דרקוני - בניסיונות להחזיר את השליטה.

מה הוא רואה: הכל, או כלום? 

מודל: Access Control List

בואו נתקדם מהמודל הנאיבי 2 צעדים קדימה:

1. ננהל את המשתמשים בקבוצות (בעזרת מערכת x.509/LDAP/Active Directory וכו') וננהל הרשאות לקבוצות, לא בודדים. התוצאה: הרבה פחות הרשאות לנהל.
2. נקבע היררכיה בין המשאבים, כך שאם נתנו הרשאה למודל אב - האובייקטים הבנים יורשים אותה (אלא אם הוגדר אחרת במפורש) - שוב: פחות משאבים לנהל עליהם הרשאות.

המודל יראה בערך כך:

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

מודל ה Access Control Lists (בקיצור: ACL) - מפשט את יכולת הניהול אפילו קצת יותר: הוא מאגד את ה Permissions לאובייקט אחד שנקרא ACL. נובעים מכך כמה יתרונות:

1. ה ACL הוא חלק מהמשאב. אם מזיזים את המשאב - ה ACL זז איתו, ואין צורך לנהל (ברמת הקוד) מעקב ושינויים בטבלת ההרשאות.
2. בגלל שה ACL הוא אובייקט יחיד, יש פחות רשומות לנהל (יותר software scalability) / ניתן לנהל cache יותר יעיל.

יתרונות אלו נראים קטנים - אך הם, בסופו של דבר, חשובים.

לאחר התוספות, המודל יראה כך:

היכן משתמשים במודל זה?

• מערכות קבצים כמו Windows NT או Unix
• IBM Tivoli, Cisco Network Infrastructure ומערכות Enterprise אחרות

כמובן שיש וריאציות מעט-שונות של המודל.

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

1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" - לא. מודל ה ACL שיפר את ה scalability של המודל הנאיבי, אך הוא עדיין נחשב מודל מאותגר-scalability מבחינת ניהול.
   ארגונים גדולים נוהגים לרכוש כלי ניתוח שסורקים את ה ACLs במערכות הקבצים, ומייצרות דוחות המקלים על ההבנה מה כל משתמש יכול לעשות.
2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" - פחות או יותר כן, כל עוד המשאבים מנוהלים היררכית בצורה הגיונית (מה שלעתים קרובות קורה).

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

מודל: Policy-Based Authorization

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

הרעיון הוא שהארגון יקבע סט של כללי-אבטחה / מדיניות אבטחה (Policies), יכיל אותם על משאבים, והמערכת תאכוף אותם.

למשל: "לחשבוניות שנוצרו בשבוע האחרון יש הרשאות קריאה למשתמשים מסוג x, המתחברים מתוך הרשת הארגונית".

בהפשטה, המודל יכול להראות משהו כזה:

במודל זה יש וריאציות רבות יותר ממודלים אחרים.

היכן משתמשים במודל זה?

מודל זה מקובל בעולם ה Enterprise במערכות רבות, נפוץ גם בעולם אבטחה (דוגמה מאוד פשוטה: Firewall)

1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" - !Hell No: למרות שיש הרבה פחות חוקים (policies) מ Permission במודלים הקודמים - הם עכשיו מורכבים הרבה יותר ומסובכים למעקב. ליתר דיוק ניתן לומר שמודל זה עשוי להיות מוצלח במקרים מסוימים, במיוחד כאשר כללים בסיסיים יכולים לתאר אוסף גדול מאוד של מקרים, משאבים או משתמשים (למשל: "אסור לגשת ל port 1433 בלי רשות של רגע ודודלי").
   קל במודל להגדיר Policies באופנים שונים, ברמות הפשטה שונות, ובסגנון שונה שיקשה על ההבנה שלהן.
2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" - שוב, מאוד תלוי.

סה"כ, מודל ה PBA הוא שנוי במחלוקת לגבי היכולת שלו לפשט את ניהול ההרשאות במערכת ה Enterprise Scale.

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

מודל ה PBA יכול גם לסבול מבעיות software scalability קשות, כאשר מספר ה policies עולה. בחלק מהמערכות, "מקמפלים" את ה policies לאוטומט שיוכל לבצע את אימות ה policies בצורה יעילה יותר.

מודל ה Role-Based Authorization

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

מודל ה Role-Based Authorization (בקיצור: RBA) הוא מודל נוסף שמנסה לתאר את הארגון וצרכיו, ולא רק להיצמד למבנה המשאבים הטכני.

במודל ה RBA ממדלים Role ("תפקיד") כסט של מטלות (Tasks) לביצוע. אנשים שאמורים לבצע מטלות דומות, לרוב יהיו בתפקידים זהים או דומים. לאותם בעלי תפקידים דומים נותנים סט של הרשאות על משאבים.

בצורה הפשוטה ביותר ניתן לבטא את מודל ה RBA באופן הבא:

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

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

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

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

לגישה זו יש מספר תוצרים:

1. למשתמשים תהיה גישה למשאבים שהם לא זקוקים להם (כי עמיתים מקבילים להם היו זקוקים להם לעבודתם). כלומר: ההרשאות הן לא "מינימליות".
2. הרבה יותר קל ופשוט לנהל את ההרשאות:
1. אם ל"רופא" אחר יש הרשאה למשאב, מספיק שאוסיף אותך ל Role "רופא", כדי שתקבל "אותן הרשאות. "שכפול הרשאות" הוא פעולה דיי מסובכת עד בלתי-אפשרית במערכת שמנהלת הרשאות כ ACLs. 
2. כשעובדים מבצעים מעברי פרויקטים / תת-תפקיד, סיכוי גבוה שההרשאות שמוגדרות להם עכשיו - מספיקות. ==> תחזוקה קלה.
3. מכיוון שיש מעט קבוצות, והן מתמפות ל"שפה הטבעית של הארגון", למי שמגדיר את ההרשאות ברור הרבה יותר טוב למי הן מיועדות.
4. כאשר רוצים לבצע סקירה של המשאבים שזמינים לרופאים, קל מאוד לבדוק את ה Role של הרופאים ולראות מה זמין להם.

בואו נבחן את המודל:

1. "האם ניתן להבין בקלות מה בדיוק משתמש x מורשה לעשות?" - כן. ה Role מוכר בארגון ויש הרבה נקודות התייחסות.
2. "כאשר אני מספק למישהו הרשאה, האם קל להבין למה בדיוק אני מספק לו הרשאה?" - כן, ניתן לסקור את ה Role בקלות ולמצוא את כל המשאבים. סביר שהמשתמש מכיר את המשאבים כי הוא בעצמו חבר ב Role.

היכן ניתן למצוא את המודל?
שרתי ווב, JEE, Windows, .NET, מערכות שונות של SAP, Oracle, IBM ועוד.

סה"כ מודל ה RBA נחשב כ "Best Practice" בתעשיית ה Enterprise וכמודל מוצלח במיוחד. הוא מספק פשטות ניהול שהיא הדרך הכמעט-יחידה של ארגון לשלוט ולהבין אילו הרשאות יש לעובדים, מבלי לטרטר אותם יותר מדי. 

הנה גרסה מעט יותר מורכבת של המודל (בכדי לסבר את העין):

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

1. המודל לא מספק שליטה במידע רגיש שאמור להיות זמין לקבוצה קטנה של אנשים. במקרים אלו מספקים מודל הרשאות נוסף (למשל: ACL למשאבים רבים - כמו קבצים, PBA למקרים רוחביים / מופשטים כמו Ethical Wall [ב]) על גבי קבוצה מסוימת של משאבים ב Role, כלומר: מגבילים חלק מהמשאבים המשויכים ל Role לתת קבוצה של ה Role.
2. מה קורה בארגון שבו אין בעלי תפקידים ברורים? ארגונים בהם מידע מוגש על בסיס "need to know"? - מודל ה RBA פשוט לא מתאים.

סיכום

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


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

ליאור

---

[א] הנה הסבר מוצלח בנושא: https://crackstation.net/hashing-security.htm

[ב] המקרה בו 2 בעלי תפקידים לא מורשים לגשת למידע אחד של השני מסיבות אתיות. לדוגמא: משרד עו"ד שמייצג שתי חברות מתחרות בתיקים שונים. עדיין, אסור לעו"ד שמייצג את חברה א' למצוא מידע על החברה המתחרה ב'.