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

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

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

בדף הזה נסביר על אישורי SSL ועל הצפנה במעבר בין מאזן עומסים של אפליקציות (ALB) או מאזן עומסי רשת בשרת proxy שמשתמש ב-SSL לבין הלקוחות שלו. לפרטים על הצפנה במעבר בין מאזן העומסים של Google Cloud לבין הקצוות העורפיים שלו, קראו את המאמר הצפנה לקצוות העורפיים.

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

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

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

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

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

סוגי אישורים

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

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

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

  • אימות דומיין (DV)
  • אימות ארגון (OV)
  • אישורי Extended Validation‏ (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 במסמכי התיעוד בנושא איזון עומסים.

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

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

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

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

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

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

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

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

      • ההתאמה מתבצעת גם לפי השם הנפוץ (CN) וגם לפי השם החלופי של הבעלים (SAN) במאפייני האישור. שמות הדומיינים במאפיינים CN ו-SAN יכולים להכיל רק אותיות קטנות. אישורים עם אותיות רישיות בשמות הדומיינים מוחזרים רק כשהם מוגדרים כאישור הראשי בשרת ה-proxy לחלוקת העומס.

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

        • התאמה מדויקת של שם המארח: התאמות מדויקות ל-CN או ל-SAN מקבלות עדיפות על פני התאמות לתו כללי לחיפוש.

        • התאמה של שם מארח עם תו כללי לחיפוש: אם אין התאמה מדויקת, מאזן העומסים בודק אם יש התאמה של CN או SAN עם תו כללי לחיפוש. תו כללי לחיפוש (*) תואם רק לתת-הדומיין ברמה הראשונה (לדוגמה, *.pets.example.com תואם ל-cats.pets.example.com ולא ל-*.example.com).

        • סוג מפתח האישור: עדיף להשתמש באישורי ECDSA על פני אישורי RSA.

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

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

        • אישור א'

          • ‫CN:‏ cats.pets.example.com
          • ‫SAN:‏ cats.pets.example.com,‏ *.pets.example.com,‏ *.example.com

        • אישור ב'

          • ‫CN:‏ dogs.pets.example.com
          • ‫SAN:‏ 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 נכשל אם הלקוח לא תומך בסט אלגוריתמים להצפנה (cipher suite) שכולל את אלגוריתם המפתח הציבורי (ECDSA או RSA) של האישור שנבחר על ידי מאזן העומסים.

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