סקירה כללית של אישורי SSL

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

‫Transport Layer Security ‏ (TLS) משמש להצפנת מידע בזמן שהוא נשלח ברשת, ומספק פרטיות בין לקוח לשרת או למאזן עומסים. מאזן עומסים של אפליקציות או מאזן עומסי רשת בשרת proxy שמשתמש ב-SSL דורש לפחות מפתח פרטי אחד ואישור SSL.

שיטת ההגדרה של האישור

במאזני עומסים של אפליקציות שמשתמשים בשרתי proxy של HTTPS ליעד, שרת ה-proxy ליעד של מאזן העומסים צריך להפנות ל-אישורי SSL של Compute Engine (בין אחד ל-15). כל משאב של אישור SSL ב-Compute Engine מכיל את המפתח הפרטי, את האישור התואם וגם אישורי CA (אופציונלי).

תמיכה במאזן עומסים

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

מאזן עומסים שיטת ההגדרה של האישור
אישורי SSL ב-Compute Engine Certificate Manager (מפת אישורים) Certificate Manager (אישורים פרטיים)
מאזני עומסים של אפליקציות (proxy ל-HTTPS עם יעד)
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) בניהול עצמי
בניהול Google 		בניהול עצמי
בניהול Google
מאזן עומסים פנימי אזורי של אפליקציות (ALB) בניהול עצמי
בניהול Google 		בניהול עצמי
בניהול Google

סוגי אישורים

אתם יכולים ליצור אישורי SSL בניהול עצמי למאזני העומסים שלכם.

אישורי SSL בניהול עצמי

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

  • אימות דומיין (DV)
  • אימות הארגון (OV)
  • אישורים עם אימות מורחב (EV)

אפשר ליצור אישורי SSL בניהול עצמי באמצעות משאבי אישורי SSL של Compute Engine. מידע נוסף זמין במאמר שימוש באישור SSL בניהול עצמי.

סוגי מפתחות נתמכים

סוגי המפתחות הבאים נתמכים באישורי SSL אזוריים ב-Compute Engine שמנוהלים על ידיכם:

  • RSA-2048
  • RSA-3072
  • RSA-4096
  • ECDSA P-256
  • ECDSA P-384

שימוש באישור עם מפתחות ECDSA

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

באיזה סוג מפתח להשתמש

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

אלה כמה מהסיבות האפשריות לשימוש בסוגים אחרים של מפתחות אישורים:

  • אם אתם צריכים לתמוך בלקוחות מדור קודם שלא תומכים באישור ECDSA, אתם יכולים לספק אישורי RSA-2048 בנוסף לאישורי ECDSA P-256.
  • אם יש לכם דרישות תאימות ספציפיות שמחייבות שימוש בגדלים גדולים יותר של מפתחות או בסוגים מסוימים של מפתחות, אפשר להשתמש במפתחות ECDSA P-384,‏ RSA-2048,‏ RSA-3072 ו-RSA-4096.

למה כדאי לבחור ב-ECDSA במקום ב-RSA

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

לדוגמה:

  • מפתח ECDSA של 256 ביט מספק רמת אבטחה דומה למפתח RSA-3072.
  • מפתח ECDSA של 384 ביט מספק רמת אבטחה גבוהה יותר מכל גודל מפתח RSA שנתמך באופן נרחב.

היתרונות העיקריים של ECDSA:

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

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

אישורי SSL מרובים

ב-proxy היעד של מאזן עומסים של אפליקציות אפשר להפנות לעד 15 אישורים של SSL ב-Compute Engine. המשאב הראשון של אישור ה-SSL של Compute Engine שאליו יש הפניה הוא אישור ברירת המחדל (הראשי) של ה-proxy של היעד.

מידע נוסף זמין במאמרים בנושא שרתי proxy של יעד ואישורי SSL במסמכי התיעוד בנושא איזון עומסים.

תהליך בחירת האישור

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

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

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

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

    • אם הלקוח לא שלח שם מארח של SNI ב-ClientHello, מאזן העומסים משתמש באישור הראשון ברשימת האישורים שלו.

    • אם הלקוח שולח שם מארח של SNI שלא תואם לשם נפוץ (CN) של אף אישור, ושלא תואם לשם נושא חלופי (SAN) של אף אישור, מאזן העומסים משתמש באישור הראשון ברשימת האישורים שלו.

    • בכל מצב אחר: מאזן העומסים בוחר אישור באמצעות תהליך ההתאמה הבא:

      • ההתאמה מתבצעת לפי הסיומת הארוכה ביותר מול השם הנפוץ (CN) ומול שם חלופי של בעלים (subject) של מאפייני האישור, עם עדיפות לאישורי ECDSA על פני אישורי RSA.

      • כדי להמחיש את שיטת ההתאמה, נניח שיש proxy ליעד שמפנה לשני האישורים הבאים:

        • אישור א'

          • ‫CN: cats.pets.example.com
          • ‫SANs: cats.pets.example.com, *.pets.example.com, *.example.com

        • אישור ב'

          • ‫CN: dogs.pets.example.com
          • ‫SANs: dogs.pets.example.com, *.pets.example.com, *.example.com

      • עכשיו נבחן את התרחישים הבאים:

        • אם שם המארח של SNI שנשלח על ידי הלקוח הוא cats.pets.example.com, מאזן העומסים משתמש באישור א'.
        • אם שם המארח של SNI שנשלח על ידי הלקוח הוא ferrets.pets.example.com, אין התאמה מדויקת, ולכן מאזן העומסים בוחר באחד מהאישורים, אישור א' או אישור ב', כי שניהם כוללים את *.pets.example.com ברשימת ה-SAN שלהם. במצב הזה, אין לכם אפשרות לשלוט באישור שנבחר.

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

המאמרים הבאים