27.8K

הסבר על תעודות אבטחה SSL Certificate

---

מאמרים קשורים:

הסבר על תקשורת מאובטחת SSL \ TLS הצפנה RSA ומנגנון החלפת מפתחות Diffie Hellman
הסבר על תעודות אבטחה SSL Certificate
הסבר על Public Key Infrastructure
יצירת תעודת אבטחה דיגטלית והתקנת התעודה ב Apache
Certificate Authority, Enterprise,Standalone והסבר על תעודות
מאמרים ישנים יותר
הסבר על תעודות אבטחה ויצירתם דרך Linux

---

Digital Signatures

תחילה נבין מהו Digital Signatures, חתימה דיגטלית, היא מצב בו משתמש "חותם" מסמך, קובץ, אימייל וכו', החתימה מייצרת מצב בו המשתמש מייצר זוג מפתחות על ידי RSA האחד Private Key והשני Public Key, המשתמש חותם את התעודה עם ה Private Key שלו ושולח למשתמש אחר, המשתמש הזה פותח המסמך ויכול לראות שאותו אדם חתם על המסמך ולכן המסמך אוטנטי.

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

1. המשתמש מייצר על ידי RSA זוג מפתחות Key-Pair האחד Private Key והשני Public Key
2. המשתמש מייצר על ידי Hash אלגוריתם כמו MD5 את הmessage-digest של המידע
3. המשתמש, משתמש בPrivate Key על מנת לחתום את הmessage-digest וכך נוצר ה"חתימה הדיגטלית"
4. המשתמש שמקבל את המסמך חתום, פותח את החתימה הדיגטלית על ידי ה Public Key של המשתמש ששלח לו את המסמך

Digital Certificate

תעודות אבטחה, המטרה של תעודות אבטחה זה לאמת ולזהות את האתר או השירות אליו אתם נכנסים, התעודה מונפקת על ידי  Certification Authority יישות מוסמכת להנפקת תעודות כמו Verisign Symantec וחברות נוספות, שמאושרת בעולם להנפיק תעודות וכך כל מחשב ברשת יכול לסמוך על התעודות שאותם חברות הנפיקו

Certificate Authority

כאשר משתמש רוצה ליצור תעודת אבטחה לאתר שלו הוא פונה ל Certificate Authority למשל Comodo, אך אנחנו יכולים לדעת שהם Certificate Authority?

במחשב שלכם אם תפתחו MMC על ידי לחיצה על WindowsKey + R או תפתחו את Run ותרשמו MMC

כעת לחצו על Certificate

בחרו ב Computer Account

המשך

נוכל לראות שיש ברשימה COMODO RSA Certification Authority, זה אומר שהמחשב שלי סומך על ה Certificate Authority הזו

כאשר המשתמש פונה לחברה הזו, החברה מבקשת פרטים מזהים על האתר כמו כתובת האתר ופרטים נוספים, המשתמש מזין כתובת אימייל לרוב Admin@domain.com או hostname@domain.com שכן רק למנהל הדומיין יש גישה לכתובות האלו, המשתמש מאשר שהוא אכן הבעלים של הכתובת דומיין הזו והCertificate Authority נותנת לו את ה Public Key ואת ה Private key
המשתמש מזין לאתר את התעודה המכילה את ה Public Key ואת ה Private Key אל תוך האתר, אך את ה Private Key האתר שומר לעצמו ואילו ה Public Key קיים בתוך התעודה עצמה

CA Hierarchy

לCertification Authority יש היררכיה, לכל שרת CA יש Root CA שהוא השרת הראשי שמנפיק את התעודות וכל מי שמקבל ממנו תעודות או שנכנס לאתר שאותו ה Root CA העניק תעודה הם סומכים גם על האתר הזה

One Tier Hierarchy

הוא שרת ששמו Subordinate CA והוא יכול להנפיק תעודות בשמו של ה Root CA, בגלל שה Root CA מכיל את הPrivate Key שמייצר את כל התעודות לרוב מכבים את ה Root CA ונותנים ל Subordinate CA לחלק את התעודות, השם הרחב יותר הוא Intermediate CA

Two Tier Hierarchy

עוד שרת Subordinate CA שמחלק תעודות בשמו של ה Root CA והוא מתחת לשרת ה Subordinate CA ברמה הראשונה

Three Tier Hierarchy

פחות נפוץ, אבל זה שרת נוסף של Subordinate CA שמדורג שלישי והוא מחלק תעודות בשמו של ה Root CA

Chain Of Trust

כאשר אתם נכנסים לאתר ובודקים את התעודה שלו, התעודה תכיל את ה Public Key של האתר, אבל אם נבדוק את נתיבי האישור

נוכל לראות שיש כמה תעודות מעל התעודה, את Comodo Secure ומתחתיו את Comodo RSA Domain Validation Secure Server CA שהוא ה Subordinate CA ורק אז מתחת את התעודה שהונפקה לאתר

זה נקרא Chain Of Trust התעודה העליונה הנפיקה את התעודה השניה מתחת שהנפיקה את התעודה של האתר, ללא התעודה הראשונה והשניה במחשב שלי, המחשב שלי לא יסמוך על התעודה שהנפיקה את זה, כיצד בודקים?

שוב נחזור ל MMC ולרשימת התעודות

ניכנס ל Comodo RSA ונוכל לראות בנתיבי האישור שמי שהנפיק את התעודה הזו זה Comodo Secure

CSR

קיצור של Certificate Signing Request, הצורה בה אנו מבקשים משרת CA תעודה, סוג התעודה הנפוץ ביותר להיום הוא PKCS 10 וחלקכם מזהים את הדרישות שלו כמו:

• Common Name
• Business Name
• Dapartment
• City
• State
• Country
• Email Address

כאשר תרצו לקנות תעודה אבטחה לאתרכם , המנפיק יבקש CSR, זאת אומרת שתיצרו בקשה לתעודה ואז תעלו לו
כך בעצם המנפיק לא יוצר את ה Private Key ואינו מודע אליו, הCSR מכיל את פרטי הבקשה, והמנפיק מייצר מהCSR את ה Public Key שזה התעודה ה crt שאתם צריכים לשים בשרת על מנת שהמשתמשים יקבלו Https

בקישור הבא בוויקיפדיה, תוכלו לראות את כל סוגי הPKCS לפי סוג הדרישה לתעודה למשל PCKS 5 ניתן למצוא במאמר באתר "הסבר על PGP הסבר על חתימה דיגטלית ויצירת מפתחות ע"י GPG" שם אני משתמש בתעודה מסוג PKCS 5

AIA – Authority Information Access

כאשר הדפדפן נכנס לאתר \ המחשב לתוכנה התעודה צריכה לא רק להיבדק שכל התעודות בהיררכיה נמצאות לוקאלית על המחשב, התעודה תכיל נתיב AIA ששם יוכלו המשתמשים להוריד את התעודה של אותו מנפיק שבמקרה הזה חברת Comodo

CDP – CRL Distribution Point

הCDP מכיל Certification Revocation List, על מנת שהמחשב יסמוך על התעודה חייבת להיות לו גישה ל CRL שכן ה CRL מכיל רשימה של כל התעודות שהיישות העליונה ה Certificate Authority אינה סומכת עליהם, מדוע יהיה לCertificate Authority תעודות שהיא לא סומכת עליהם? במקרה בו האתר נפרץ או שהמפתח נגנב אותו Private Key יכול לשמש את התוקף לפענח את ההצפנה שבין האתר לבין הלקוח, לכן האתר מודיע לחברה שהנפיקה לו את התעודה שהPrivate Key נגנב ואז המנפיק יכניס את התעודה ל CRL.

RA

הוא קיצור של Registration Authority בPKI של מייקרוסופט (מאמר שקיים באתר, קישור נמצא למעלה) הוא ה Subordinate CA והוא מוסמך על ידי ה Root CA להנפיק תעודות למשתמשים נאמר בAD או לאתרי Web בכללי והמטרה שלו היא יותר אבטחתית שכן ניתן לכבות את ה Root CA ולהשאיר את ה Subordinate CA שיחלק תעודות ויאמת את המשתמשים המורשים לקבל תעודה.

OCSP

הוא קיצור של Online Certificate Status Protocol והוא אחראי להשיג אם תעודה מסוג X.509 (סוג התעודה ומה היא מכילה) הוסרה\נחסמה (Revocation Status), סה"כ זאת אומרת שהוא עוד פ'יצר בדומה ל CRL
* הוא מכיל פחות מידע ובכך פחות מעמיס על התעודה \ הרשת

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

מה תעודה מכילה?

גרסת התעודה – גרסה מספר 3 של התעודה

מספר סידורי – המספר הסידורי של התעודה הסצפציפית הזו

אלגוריתם חתימה – באיזה הצפנה השתמשו על מנת להצפין את התעודה – SHA256RSA

Hash אלגוריתם של החתימה – באיזה Hash השתמשו SHA256

מנפיק – ה Certificate Authority שהנפיק את התעודה

בתוקף מ – ממתי התוקף של התעודה

בתוקף עד – עד מתי התעודה תקפה

נושא: מידע כמו לאיזה כתובת ניתנה התעודה

מפתח ציבורי: ה Public Key של התעודה

מזהה המפתח של הנושא: מפתח ציבורי לאימות התעודה

רכיבי מדיניות האישורים: CPS מכיל בתוכו תיאור של כיצד ה Certificate Authority מנפיקה תעודות ובאילו שיטות השתמשו

נקודת הפצה של רשימות CRL: הוסבר למעלה מהו CRL

גישה למידע הרשות: גישה לAIA

שם חלופי של נושא: לאיזה כתובות הונפקה התעודה, רק לך Systal.co.il ו www.systal.co.il

שימוש במפתח: נתונים של התעודה עצמה

מגבלות בסיסיות: אילו מגבלות חלות על התעודה

מגבלות בסיסיות: מגבלות נוספות שקיימות על התעודה

אלגוריתם של תמצית: איזה Hash Algorithem השתמשו על מנת לוודא על שלמות התעודה SHA1

Http Vs Https

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

האתר הוא בפורט Http 80 זאת אומרת שאינו מאובטח

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

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

כאשר אתם מתחברים לאתר מאובטח התצוגה תוצג כך

זאת אומרת שהאתר מאובטח שכן ההתחלה שלו מתחילה ב Https פורט 443

לדוגמה נגלוש לאתר Systal.co.il

כאשר נלחץ בגוגל על F12 במקלדת ונלחץ על הלשונית Security

ונלחץ על View Certificate

נגיע לתעודת האבטחה של האתר

נראה את הפרטים הבאים:

הונפק עבור: Systal.co.il

זאת אומרת שהתעודה הונפקה עבור הכתובת הזו בלבד

ולתעודה יש תוקף עד 11/01/2018

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

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

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

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

במחשב שלכם אם תפתחו MMC על ידי לחיצה על WindowsKey + R או תפתחו את Run ותרשמו MMC

כעת לחצו על Certificate

בחרו ב Computer Account

המשך

ותראו רשימת תעודות

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

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

ממה בנויה תעודה?

דוגמה ממדריך אחר באתר התקנת תעודת אבטחה ב Apache שמציג כיצד יוצרים תעודה ומתקינים אותה

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

[root@localhost ~]# sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/certs/shushan.key -out /etc/ssl/certs/shushan.crt

הפקודה בנויה כך:

req -x509 – מבקש תעודה מסוג x509 שהיא נפוצה מאוד בעולם ה PKI ליצירת תעודות אבטחה

-days 365 – כמה זמן תיהיה התעודה תקפה

-newkey rsa:2048 – הצפנה של 2048 סיביות RSA

shushan.key – הוא ה Private Key

shushan.crt – ה Public Key והתעודה עצמה שתגיע לידי המשתמש כאשר הוא יכנס לאתר

כך הקבצים נראים במחשב:

לחיצה פעמיים על shushan.crt תעלה את המסך הבא

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

נקבל את ה Public Key, שבתחילתו רשום

—–BEGIN CERTIFICATE—–

ובסופו

—–END CERTIFICATE—–

כעת נפתח את ה shushan.key גם בכתבן, זהו ה Private Key

ניתן לראות ששם רשום בהתחלה

—–BEGIN PRIVATE KEY—–

ובסוף

—–END PRIVATE KEY—–

 

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

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

כאשר מתחברים לאתר כיצד ההצפנה עובדת?

כמו שאמרנו עד כה ה Public Key הוא למעשה ציבורי וכולם יכולים לראות אותו, אבל עניין חשוב מאוד הוא שכאשר ה Public Key יצפין מידע מסוים, יהיה ניתן לפתוח אותו רק על ידי ה Private Key אשר יושב בשרת

כאשר המשתמש נכנס לאתר הדבר הראשון שקורה הוא Hello:

 – Handshake Hello

המשתמש מתחיל תהליך של "לחיצת ידיים" Handshake, המשתמש שולח לשרתClientHello ובו את המידע על איזה גרסה של SSL יכול המשתמש לתמוך ופרמטרים נוספים.
לאחר מכן השרת שולח ServerHello ובו ההגדרות של איזה TLS הם ישתמשו בינהם ואיזה cipher suite

Certificate Exchange

כאשר התקשורת התחילה, השרת חייב להוכיח למשתמש שהוא האתר שהוא מציג עצמו, האתר מציג למשתמש את תעודת האבטחה שלו ובה כל הפרטים המזהים: הכתובת האתר, המנפיק, ה Public Key וכו'
המשתמש בודק את התעודה אל מול הTrusted Root Certificate Authority ואם הכל תקין הם יתחילו את החלפת המפתחות.

Key Exchange – החלפת מפתחות

בשלב ה Hello השרת והלקוח מחליטים על צורת ההצפנה סימטרית ואסימטרית, מדוע על ידי שניהם?
הלקוח משתמש ב Public Key של השרת על מנת להצפין "מפתח" סימטרי – זוג מפתחות שגם מצפינות וגם פותחות את ההצפנה
הלקוח שולח את אחד המפתחות לשרת על ידי כך שהוא הצפין אותו על ידי ה Public Key של השרת, השרת פותח את ההצפנה שיש על המפתח על ידי ה Private Key שלו

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

תוכלו לבדוק באתר https://www.ssllabs.com/ssltest/ האם התעודה שלכם תומכת ב Forward Secrecy

אם הPrivate Key נגנב?

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