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 והצורך לצייר על מרחב גדול יותר), שמשפר את כלל ביצועי המכשיר.