SSL / TLS 101 למתחילים

מבט מעמיק על ההצפנה המאבטחת את חיבורי האינטרנט שלנו


בעוד שנטסקייפ המציאה במקור את SSL באמצע שנות ה -90, זה לא התחייב לכל אתר להתקין תעודת SSL / TLS עד קיץ 2018 כאשר גוגל החלה לסמן אתרים לא מוצפנים “לא מאובטח.”

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

הסיבה לכך היא פשוטה: ללא SSL / TLS והיכולת להתחבר בצורה מאובטחת באמצעות HTTPS, כל התקשורת בין אתרים למבקרים שלהם תוחלף בפשטות וניתנת לקריאה בקלות על ידי צד שלישי..

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

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

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

יסודות יסוד

נתחיל בדיון במושג שנמצא בלב ליבו של כל זה: הצפנה.

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

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

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

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

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

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

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

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

התשובה הייתה הצפנה.

סוגיית החלפת מפתחות

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

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

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

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

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

נהדר, אבל איך זה מועיל?

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

אבל איך מחליפים מפתחות? במיוחד ברשת?

הצפנת מפתח ציבורי.

וזה, המזוקק עד עצם מהותו, הוא מה ש- SSL / TLS עוסק בו: החלפת מפתחות מאובטחת.

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

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

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

עכשיו נעבור על כמה מונחי מפתח

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

היה צורך בפרוטוקול מאובטח יותר. לפיכך, HTTPS.

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

בעוד שבימיו הראשונים של האינטרנט חיבור היה ישיר באופן סביר, כעת החיבורים מנותבים דרך עשרות מכשירים בדרך ליעדם הסופי. אם רצית אי פעם הדגמה מעשית של זה, פתח את שורת הפקודה במערכת ההפעלה שלך והזן את הפקודה “tracert geekflare.com.”

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

זה נקרא התקפה של איש באמצע (MITM).

אם אתה רוצה ללמוד על התקפת MITM, אז עיין בקורס המקוון הזה.

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

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

לרוע המזל, המונחים SSL / TLS, HTTPS, PKI והצפנה מסתובבים הרבה, לפעמים אפילו משתמשים זה בזה להחלפה, כך שיביאו כל בלבול מתמשך, הנה מדריך מהיר:

  • SSL – שכבת שקעים מאובטחים, פרוטוקול ההצפנה המקורי המשמש עם HTTPS
  • TLS – אבטחת שכבת תעבורה, פרוטוקול ההצפנה העדכני ביותר שהחליף את SSL
  • HTTPS – הגרסה המאובטחת של HTTP, המשמשת ליצירת חיבורים עם אתרים
  • PKI – תשתית מפתח ציבורי, מתייחסת לכל מודל האמון המאפשר הצפנת מפתח ציבורי

SSL / TLS פועל בשילוב כדי לאפשר חיבורי HTTPS. ו- PKI מתייחס לכל העניין כשאתה מתקרב.

הבנת? אל תדאג, כן.

בניית תשתית מפתח ציבורית

כעת, לאחר שהניחנו את הבסיס, נתקרב ונראה את הארכיטקטורה המופעלת על ידי מודל האמון בלב SSL / TLS..

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

אז נתחיל בהצבת השאלה: כיצד המחשב שלי יודע אם לסמוך על תעודת SSL / TLS נתונה?

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

רשויות תעודה

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

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

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

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

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

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

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

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

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

תוכניות שורש

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

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

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

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

שרשראות תעודה

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

כאן נכנס לתמונה מושג שרשור האישורים.

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

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

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

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

סוגי תעודות SSL / TLS ופונקציונליות

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

מוקדם יותר הזכרנו כי התקנת אישור TLS מאפשרת לך להגדיר את אתר האינטרנט שלך ליצירת חיבורי HTTPS דרך יציאה 443. זה גם משמש מעין תג שם לאתר או לשרת שאיתו אתה מתקשר. כשחוזרים לרעיון שבליבה, SSL / TLS ו- PKI הם כולם צורות נהדרות של החלפת מפתחות מאובטחת, תעודת ה- SSL / TLS עוזרת להודיע ​​לדפדפן למי הוא שולח את מפתח ההפעלה – למי המסיבה בקצה השני של הקשר הוא.

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

  • כמה זהויות לטעון
  • אילו נקודות קצה לטעון זהות

תשובה לשתי השאלות האלו תעניק לך אינדיקציה די ברורה לאיזה סוג תעודה אתה זקוק.

כמה זהויות לטעון

קיימות שלוש רמות אימות שונות עם תעודות SSL / TLS, והן משתנות בהתאם לכמות מידע זהות שהאתר שלך רוצה לטעון..

  • אישורי תחום אימות SSL – טען זהות שרת
  • אישורי ארגון אימות SSL – קבע זהות ארגון חלקית
  • תעודות SSL לאימות מורחבות – טען זהות ארגון מלאה

אישורי תחום אימות SSL הם ללא ספק הפופולריים ביותר בגלל מחירם ומהירות ההנפקה שלהם. אישורי DV SSL / TLS דורשים בדיקת בקרת תחום פשוטה, שניתן לבצע בכמה דרכים שונות, אך ברגע שהיא יכולה להנפיק את האישור. אתה יכול גם לקבל כמה גרסאות של 30 יום ו 90 יום של אלה בחינם, שללא ספק הוסיפו את נתח השוק שלהם.

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

אישורי ארגון אימות SSL הם הסוג המקורי של תעודת SSL / TLS. הם גם הסוג היחיד של אישור SSL שיכול לאבטח כתובת IP בעקבות החלטת 2016 של פורום CAB לבטל את כל אישורי ה- SSL האינטרא-נט. אימות ארגוני דורש הצבת עסק קלילה וניתן בדרך כלל להוציאו תוך יום-יומיים – לפעמים מהר יותר. תעודות SSL של OV מציינות מידע ארגוני כלשהו, ​​אך משתמש אינטרנט יצטרך ללחוץ על סמל המנעול ולחפש אותו. בימינו רואים הרבה תעודות OV SSL הפרוסות ברשתות ארגוניות וארגוניות גדולות, עבור חיבורים שנעשו מאחורי חומת אש למשל.

מכיוון שלא אישורי DV או OV SSL מעידים על זהות מספקת כדי לספק את מרבית הדפדפנים שהם מקבלים טיפול ניטרלי.

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

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

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

על אילו נקודות קצה לטעון זהות

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

לא משנה מה ההקשר, יש תעודת SSL / TLS שיכולה לעזור בהבטחתו.

תחום יחיד

האתר הראשי ותעודת ה- SSL הסטנדרטית הם רק תחום יחיד. מרבית אישורי ה- SSL / TLS המודרניים יאבטחו גם את גרסאות ה- WWW וגם את הגרסאות הלא-WWW של אותו תחום, אך הן מוגבלות לתחום יחיד. אתה יכול השווה את תעודות ה- SSL כאן.

ריבוי דומיינים

תעודות מרובות דומיינים או אישורי תקשורת מאוחדים (במקרה של שרתי Microsoft Exchange ו- Office Communications) קיימים גם כדי לאפשר לארגונים להצפין דומיינים מרובים באמצעות אישור יחיד. זו יכולה להיות אופציה אטרקטיבית מכיוון שהיא חוסכת כסף והיא הופכת את ניהול התעודות (תפוגה / חידוש) לפשוט הרבה יותר.

אישורי ריבוי דומיינים ו- UCC משתמשים ב- SAN, השדה שם חלופי לנושא ב- CSR, כדי להוסיף תחומים נוספים לתעודה. מרבית רשות הרשות מאפשרת עד 250 רשימות SAN שונות בתעודה יחידה. ורוב האישורים המרובי-דומיינים מגיעים עם 2-4 SANs ללא תשלום והשאר זמינים לרכישה לפי הצורך.

תעודות SSL של Wildcard

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

  • app.website.com
  • portal.website.com
  • user.website.com

אתה יכול להצפין את כולם עם אותה תעודה Wildcard באמצעות כוכבית בשדה FQDN של CSR שלך: * .website.com

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

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

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

Wildcard מרובה דומיינים

תוספת חדשה יחסית למערכת האקולוגית SSL / TLS, Multi-Domain Wildcard יכולה להצפין עד 250 דומיינים שונים, אך היא יכולה גם להשתמש בכוכבית בשדות SANs, המאפשרת גם להצפין 250 דומיינים שונים וכל מה שנלווה אליהם קודם. -מדומיינים נמוכים.

מקרה שימוש אחר עבור Wildcard Multi-Domain הוא כ- Wildcard מרובה רמות, שם הוא יכול להצפין תחומי משנה ברמות מרובות של כתובת האתר (Wildcard רגיל יכול להצפין אותם רק ברמה אחת).

בגלל הפונקציונליות של Wildcard, גם Wildcards עם ריבוי דומיינים אינם זמינים ב- EV.

SSL / TLS בתנועה

כעת, כאשר כיסינו את כל המושגים המשמעותיים שמאפרים SSL / TLS ו- PKI, בואו נרכיב את הכל ונראה את זה בתנועה.

אימות והנפקה

נתחיל את כל הדרך בהתחלה עם אתר שרוכש תעודת SSL / TLS מטעם CA או משווק. לאחר הרכישה איש הקשר הארגוני המטפל ברכישת האישור יוצר בקשה לחתימת אישורים בשרת בו יותקן האישור (השרת המארח את האתר).

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

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

כעת בעל האתר יכול לקחת את אישור ה- SSL / TLS שזה עתה הונפק, להתקין אותו בשרת שלו ולהגדיר את האתר ליצירת חיבורי HTTPS ביציאה 443 (באמצעות הפניות מחדש של 301 כדי לשלוח תנועה מדפי HTTP הקיימים לפני עמיתיהם החדשים של HTTPS).

אימות ולחיצת יד SSL

כעת, כאשר מותקן תעודת SSL / TLS, והאתר הוגדר כ- HTTPS, בואו נראה כיצד הוא יאפשר חיבורים מוצפנים עם מבקרי האתר..

עם הגעתו לאתר, השרת יציג את אישור ה- SSL / TLS לדפדפן המשתמש. לאחר מכן דפדפן המשתמש מבצע סדרת בדיקות.

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

עכשיו זה לחיצת יד.

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

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

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

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

וזה SSL / TLS.

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

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

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

לפני שאתה הולך, נסיים עם כמה מהלכים הקשורים ל- SSL / TLS שתוכל לבצע לאחר ההתקנה / תצורה כדי להפיק את המרב מההשקעה שלך.

לאחר SSL / TLS – הפקת המרב מהיישום שלך

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

השבת את תמיכת השרת לפרוטוקולים ישנים

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

SSL 2.0 ו- SSL 3.0 הם שניהם בני יותר מ 20 שנה. השיטה הטובה ביותר הייתה לבטל את התמיכה בהם לפני שנים, אך עד היום כ- 7% מכלל אלפי האלפיים המדורגים עדיין מאפשרים להם. זה מסוכן מכיוון שהוא חושף אותך להתקפות SSL ולהורדת מדרגות כמו POODLE.

גם TLS 1.0 ו- TLS 1.1 הם זמן שאול.

חברות הטכנולוגיה הגדולות, אפל, מיקרוסופט, גוגל ומוזילה, פרסמו בסתיו הקרוב כי הן יפסלו את התמיכה ב- TLS 1.0 ו 1.1 בתחילת 2020..

גרסאות הפרוטוקול רגישות לפגיעויות כמו POODLE, FREAK, BEAST ו- CRIME (כל אלה ראשי תיבות). TLS 1.2 נמצא כבר עשר שנים והוא אמור להיות הסטנדרט. TLS 1.3 הושלמה בקיץ האחרון והאימוץ נע בקצב קבוע מאז.

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

אלגוריתמים / צופים מוצעים:

  • החלפת מפתחות: עקומת אליפטית דיפי-הלמן (ECDH)
  • אימות: עקומת אליפטית אלגוריתם חתימה דיגיטלית (ECDSA)
  • הצפנה סימטרית / גורפת: AES 256 במצב מונה של גלואה (AES256-GCM)
  • אלגוריתם MAC: SHA-2 (SHA384)

SSL מתמיד

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

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

עליך להגדיר את התצורה של כל האתר שלך ל- HTTPS. זה נקרא SSL תמיד-על. אחרי הכל, זה לא כאילו שאתה משלם לפי הדף, אישור ה- SSL / TLS שלך יכול להצפין את כל האתר שלך. אז תעשה את זה כך.

הגדר רשומת רשות אישורים (CAA)

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

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

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

הוסף את האתר שלך לרשימת ההעלאה מראש של HSTS

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

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

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

שאלות נפוצות בנושא SSL / TLS

מה זה אישור X.509?

X.509 מתייחס לסוג האישור הדיגיטלי שמשמש עם SSL / TLS וסוגים אחרים של PKI. X.509 הוא תקן הצפנת מפתח ציבורי. לעיתים תראה שחברות משתמשות בתעודת X.509 במקום ‘תעודה דיגיטלית’ או ‘תעודת PKI’.

מדוע פג תוקף אישורי SSL / TLS?

ישנן שתי סיבות לכך.

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

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

איך מחדשים אישור SSL / TLS?

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

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

מהי בדיקת HTTPS?

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

מהי הורדת SSL?

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

מדוע הרשות הפלסטינית שלי שלחה לי תעודת ביניים?

זכור קודם לכן כשדיברנו על תוכניות שורש?

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

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

איזה תיעוד אני זקוק לתעודת SSL Validation Validation?

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

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

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

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

בסגירה

אני מקווה שזה נותן לך מושג לגבי SSL / TLS. אם אתה מעוניין ללמוד עוד, אני אמליץ לוקח את הקורס המקוון הזה.

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

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map