Defaults.Exposed › תיקונים › הצפנה מודרנית (גרסת TLS וסיפרים)

כיצד לתקן הצפנה מודרנית (גרסת TLS וסיפרים)

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

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

מה זה יכול לעלות לכם

• לקוח משלם או מתחבר דרך Wi-Fi של מלון או בית קפה, גרסת חיבור מיושנת או סיפר חלש מאפשרים לזר באותה רשת לקרוא את הכרטיס והסיסמה שלהם בזמן אמת, וההונאה — ושיחת הטלפון הכועסת — מגיעה ישירות לאתר שלך.
• אתה מגיש בקשה לקבלת תשלומים בכרטיסים (או ספק התשלומים שלך מבצע ביקורת) ונדחה כי TLS מיושן או סיפר אסור שובר את כללי אבטחת התשלומים — הקלה האינטרנטית שלך מוקפאת עד שתתוקן.
• צוות ה-IT של לקוח גדול מריץ סריקת אבטחה שגרתית לפני החתימה, רואה שהאתר שלך עדיין מאפשר הצפנה שבורה, ומסמן אותך כסיכון — החוזה נעצר על בעיה שעולה כלום לתקן.
• תלונת הגנת נתונים או הפרצה נוחתות על שולחנך והשאלה הראשונה שרגולטורים שואלים היא האם הגנת על נתוני לקוחות 'כראוי' — הרצת הצפנה שנשברה בציבורית ידועה במשך שנים היא תשובה קשה מאוד לתת.
• האתר שלך מציג מנעול, כך שכולם מניחים שהוא בטוח לחלוטין, והפרצה זו עוברת ללא הבחנה במשך שנים — עד שכניסה או מספר כרטיס מיורטים אחד הופכים לאירוע הרבה יותר יקר מהתיקון החינמי שהיה יכול להיות.

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

בשפה פשוטה

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

1. גרסת TLS — איזה דור של הטכנולוגיה אתה משתמש. הגרסאות המוקדמות (TLS 1.0 ו-TLS 1.1) נשברו בציבורית שנים; הבטוחות הן TLS 1.2 ו-TLS 1.3.
2. הסיפר — המתכון הספציפי שTLS משתמש לסרבול. חלק מהסיפרים (כמו RC4, DES ו-3DES) נפרצו ואסורים כעת; הסיפרים המודרניים עדיין חזקים.

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

מה זה יכול לעלות לך

• לקוח נגנב ב-Wi-Fi ציבורית. מישהו מתחבר לחשבון שלו או משלם ממלון, בית קפה, או שדה תעופה. כי האתר שלך עדיין מאפשר גרסת TLS ישנה או סיפר חלש, זר באותה רשת מכריח את החיבור לרדת לאפשרות הניתנת לשבירה וקורא את הסיסמה ומספר הכרטיס שלהם בזמן אמת. ההונאה נוחתת על הלקוח, אבל הביוש — ושיחת התמיכה — נוחת עליך.
• תשלומי הכרטיסים שלך מכובים. כללי אבטחת תשלומים (PCI DSS) דורשים TLS 1.2 כמינימום ואוסרים במפורש על סיפרים חלשים כמו RC4. כשהמעבד שלך מבצע ביקורת, או כשאתה מגיש בקשה לקבלת כרטיסים, תצורה מיושנת נכשלת בבדיקה והקלה שלך מוקפאת עד שתתוקן — בדיוק ברגע הגרוע לתזרים המזומנים.
• עסקה נעצרת בביקורת אבטחה. לפני שלקוח גדול חותם, צוות ה-IT שלו מריץ סריקה שגרתית. הוא מסמן מיד שהאתר שלך עדיין מקבל הצפנה שבורה — סוג של ממצא שנראה רשלני וגורם לקונה לתהות מה עוד רופף. החוזה יושב בהמתנה על בעיה שעולה כלום לתקן.
• רגולטור שואל את השאלה המביכה. לאחר כל תלונה או הפרצה, הדבר הראשון שרשות הגנת נתונים רוצה לדעת הוא האם הגנת על נתונים אישיים “כראוי”. הרצת הצפנה שנשברה ידועה בציבור במשך שנים קשה מאוד להגן עליה, ו”לא הבנו שהגרסה הישנה עדיין מופעלת” אינה תשובה נוחה.
• מתחבאת מאחורי המנעול שנים. כיוון שהאתר שלך עדיין מציג מנעול רגיל, אף אחד לא שם לב לפרצה — עד שכניסה או מספר כרטיס מיורטים בודדים הופכים לאירוע ציבורי הרבה יותר יקר מהתיקון של חמש דקות שהיה יכול להיות.

מה זה בעצם

גרסת TLS

אתר לא תומך בגרסת TLS אחת בלבד — הוא יכול להציע כמה בבת אחת ולתת לדפדפן של כל מבקר לבחור. מבקר מודרני ישתמש בגרסה החדשה ביותר הזמינה ויראה מנעול רגיל. הסכנה היא שהגרסאות הישנות השבורות יכולות לשבת שם לצד האפשרויות הטובות כדלת אחורית פתוחה: תוקף יכול לכפות על החיבור של מבקר “לרדת” ל-TLS 1.0 או 1.1 ואז לנצל את נקודות התורפה הידועות בגרסאות אלה (מתקפות BEAST ו-POODLE הם הדוגמאות המפורסמות) כדי לפענח את התנועה.

כך הבדיקה שלנו מתחברת לאתר שלך ובודקת כל גרסה בנפרד — TLS 1.0, 1.1, 1.2 ו-1.3 — כדי לראות אילו שרת שלך עדיין מקבל:

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

הסיפר

ברגע שגרסה נבחרת, TLS בוחר סיפר — האלגוריתם האמיתי שמסרבל את הנתונים. רוב הסיפרים המודרניים חזקים. קומץ נשברים ואסורים לשימוש: RC4 (הסרבול שלו מוטה ומדליף את הטקסט הפשוט), DES (המפתח שלו קצר כל כך שניתן לכפות עליו בכוח), 3DES (פגיע למתקפת “Sweet32”), בנוסף NULL (ללא הצפנה כלל), סיפרי EXPORT (מוחלשים בכוונה — מתקפות FREAK ו-Logjam), וסיפרים אנונימיים (ללא בדיקת זהות).

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

שלושת התוספות האינפורמטיביות

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

• דחיסת TLS (מתקפת CRIME): תכונה ישנה שאם נשאיר מופעלת, יכולה לאפשר לתוקף לחלץ קוקיות סשן. הושבתה כברירת מחדל בכל שרת אינטרנט מודרני מעל עשור.
• OCSP stapling: שיפור ביצועים ופרטיות שבו השרת שלך ממלא מראש הוכחה שהתעודה שלו לא בוטלה, כך שכל מבקר לא צריך לשאול את רשות התעודות בעצמו. CDNs כמו Cloudflare עושים זאת אוטומטית.
• Renegotiation מאובטח: תיקון לפגיעות ישנה (CVE-2009-3555). TLS 1.3 הסיר renegotiation לחלוטין, ושרתי TLS 1.2 מודרניים מיישמים את התיקון כברירת מחדל.

כיצד לתקן (חינם, ~30 דקות)

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

הגישה הפשוטה האמינה ביותר היא ליצור תצורה ידועה-טובה ולא לכתוב אחת ביד: הדבק את סוג השרת שלך במחולל תצורת SSL של Mozilla ב-https://ssl-config.mozilla.org/ ובחר פרופיל “Intermediate” (תאימות רחבה) או “Modern” (TLS 1.3 בלבד). הוא מפיק את שורות ssl_protocols ו-ssl_ciphers הנכונות עבורך.

לפי פלטפורמה:

1. Cloudflare או מארח מנוהל — בדרך כלל לחיצה אחת או שתיים. ב-Cloudflare: SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2, וחבילות הסיפרים שם מנוהלות עבורך (הפלטפורמה לא תציע סיפרים אסורים). רוב המארחים המנוהלים ובוני האתרים (Squarespace, Wix, Shopify, מארחי WordPress מודרניים) כבר אוכפים TLS 1.2+ עם סיפרים חזקים — פשוט אשר שאין אפשרות “TLS ירושה” או “תאימות דפדפן ישן” מופעלת.

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

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

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

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS. השתמש בכלי IIS Crypto החינמי (או הגדרות רישום מקבילות) להשבית TLS 1.0 ו-1.1, להשבית RC4/DES/3DES/NULL/EXPORT, ולהשאיר TLS 1.2 ו-1.3 עם סיפרים חזקים מופעלים. תבנית “Best Practices” של הכלי עושה את כל זה בלחיצה אחת.

5. התוספות האינפורמטיביות (אופציונלי, חינמי). ב-Nginx הוסף ssl_stapling on; ssl_stapling_verify on; (עם שורת resolver) עבור OCSP stapling; ב-Apache, SSLUseStapling On. דחיסת TLS ו-secure renegotiation כבר בטוחים כברירת מחדל בשרתים מודרניים — לא נדרשת פעולה. ב-Cloudflare שלושתם מטופלים אוטומטית.

6. אמת, ואז בדוק שוב כאן. אשר שרק הגרסאות והסיפרים הבטוחים נשארים — לדוגמה עם nmap --script ssl-enum-ciphers -p 443 yourdomain.com, או בדוק בכלים המקושרים של https://ssl-config.mozilla.org/ — ואז הרץ שוב בדיקה זו. כשאפשר, אפשר TLS 1.3 לצד 1.2: הוא גם מהיר יותר וגם מאובטח יותר.

טעויות נפוצות

• “יש לנו מנעול, אז אנחנו בסדר.” המנעול מוכיח רק שחיבור מאובטח קיים. הוא לא אומר כלום על האם גרסה ישנה או סיפר אסור עדיין מקבלים ברקע — שזו בדיוק הפרצה שהבדיקות האלה מאתרות.
• תיקון הגרסה אבל לא הסיפרים (או להפך). השבתת TLS 1.0/1.1 לא מסירה אוטומטית RC4 או 3DES, ונעילת סיפרים חזקים לא משביתה אוטומטית גרסאות ישנות. הגדר את שניהם — התצורה שנוצרה למעלה עושה זאת.
• השארת מתגי “ירושה” או “תאימות דפדפן ישן” מופעלים. מארחים ו-CDNs רבים מציעים אפשרות שמחדשת בשקט את הגרסאות השבורות או הסיפרים החלשים “לתאימות”. זה כמעט לעולם לא עוזר למבקר אמיתי וגורם ישירות לממצא זה.
• שכחת לטעון מחדש/להפעיל מחדש את השרת. שינויי תצורה לא נכנסים לתוקף עד שהשרת נטען מחדש — סיבה מפתיעה נפוצה לכך שאתר “מתוקן” עדיין נכשל בבדיקה מחדש.
• תצורת שרת אחד אבל לא כולם. אם אתה מריץ load balancer, שרתי אינטרנט מרובים, או תתי-דומיינים נפרדים (shop, blog, app), כל נקודת קצה TLS צריכה את אותה התצורה — הכי חלש הוא זה שתוקף מכוון.

מה לזכור

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

שאלות נפוצות