Loading AI tools
פרוטוקול אבטחה בשכבת התעבורה מוויקיפדיה, האנציקלופדיה החופשית
Transport Layer Security (אבטחת שכבת התעבורה; בקיצור: TLS) או גרסתו המוקדמת Secure Sockets Layer (בקיצור: SSL) הם פרוטוקולי האבטחה הפופולריים והחשובים ביותר של רשת האינטרנט. כמעט כל אתרי האינטרנט המוגנים באמצעים קריפטוגרפיים מסתמכים על פרוטוקולים המהווים חלק מהחבילה SSL/TLS. מסחר אלקטרוני, בנקאות מקוונת, דואר אלקטרוני, VoIP, מחשוב ענן ועוד. TLS נתמך על ידי מרבית הדפדפנים המודרניים.
TLS הוא פרוטוקול ורסטילי שמטרתו אבטחת שיחת שרת/לקוח בשיטות קריפטוגרפיות חזקות והוא אמור למנוע ציתות, זיוף, או חבלה (שינוי זדוני) של המידע העובר בין השרת והלקוח. מאפשר חיבור אנונימי, אימות שרת (חד-צדדי) או אימות דו-צדדי, תוך שמירה על דיסקרטיות ושלמות המסרים. שלוש נקודות עיקריות שהפרוטוקול אמור לתת להן מענה הן:
בפרוטוקול תקשורת שתומך במצב מוצפן בTLS כאופציה, על הלקוח ליידע את השרת על רצונו לעבור לתקשורת מאובטחת, דרך אחת היא להשתמש בפורט ייעודי (מקובל להוסיף את האות s) שהוקצה על ידי ICANN כמו פורט 443 של HTTPS או פורטים 989/990 של FTPS. דרך אחרת היא לנצל מנגנון תלוי פרוטוקול ספציפי (כמו בקשת STARTTLS בדואר אלקטרוני) כדי לשלוח לשרת בקשה לעבור למצב של TLS.
גרסאות | |
---|---|
פרוטוקול | שנה |
SSL 1.0 | - |
SSL 2.0 | 1995 |
SSL 3.0 | 1996 |
TLS 1.0 | 1999 |
TLS 1.1 | 2006 |
TLS 1.2 | 2008 |
TLS 1.3 | 2018 |
פרוטוקול SSL המקורי פותח על ידי חברת נטסקייפ. גרסה 1.0 לא פורסמה מעולם בשל פגמים חמורים. גרסה 2.0 שוחררה בפברואר 1995. היא הסתמכה בעיקר על RSA כמערכת מפתח ציבורי עם תעודה תואמת X.509 וצופן בלוקים כמו DES, DES משולש או RC4 וכן פונקציות הגיבוב MD5 ו-SHA-1. מפני שעדיין הכילה ליקויי אבטחת מידע רבים הוחלט ב-1996 להחליפה בגרסה 3.0 שתוכננה כולה מחדש על ידי צוות מהנדסים בראשות Paul Kocher. בגרסה האחרונה הוחלפו מרבית הפרוטוקולים, נוספה תמיכה ב-פרוטוקול דיפי-הלמן, FORTEZZA (מערכת ההצפנה של ממשלת ארצות הברית) וחתימה דיגיטלית DSA והיא למעשה הבסיס של SSL/TLS המודרני בשינויים אחדים. גרסה 3 המקורית נרשמה ב-RFC 6101 למטרות היסטוריות.
פרוטוקול TLS זהה לפרוטוקול SSL גרסה 3, למעט מספר הבדלים מינוריים, בעיקר הטיפול בקוד אימות מסרים (הוספת HMAC) ושיטת גזירת המפתח. ב-TLS מפתח השיחה הוא פונקציה פסאודו-אקראית (PRF) של תוכן סודי אקראי שנוצר על ידי שני הצדדים במשותף. כמו כן מספר אלגוריתמים קריפטוגרפיים הוכרזו כמנדטוריים כמו פרוטוקול דיפי-הלמן, DSA ו-AES. גוף התקינה IETF המליץ על TLS גרסה 1.0 ב-1999 בהצעה RFC 2246 כשדרוג של SSL גרסה 3. ב-2006 פורסמה גרסה 1.1 ונכון לשנת 2015, הגרסה העדכנית היא TLS 1.3 לפי RFC 8446 שתוקננה באוגוסט 2018, והחליפה את גרסה 1.2 שהוגדרה בRFC 5246 ב-2008.
לפי מודל ה-OSI פרוטוקול TLS שוכן בשכבת השיחה, בין שכבת התעבורה (4) לשכבת היישום (7). בהקשר של פרוטוקולי האינטרנט המשמעות היא בטווח שבין TCP/IP ל-HTTP ,FTP, SMTP וכדומה. TLS אינו כולל מנגנון סינכרון מובנה ומסתמך על שכבת הקו שתחתיו. הפרוטוקול מתחלק לשתי שכבות עיקריות, כמתואר בתרשים.
בלחיצת היד משיגים שלושה יעדים:
כדי לתמוך במערכות ישנות (legacy) במהלך המשא ומתן בין השרת והלקוח לפני שמתקבלת ההחלטה לגבי גרסת הפרוטוקול, ברירת המחדל היא שהלקוח מציע את הגרסה העדכנית ביותר שהוא תומך בה ואם לחיצת היד נכשלת מתחיל משא ומתן של הורדה בגרסאות (downgrade). למשל אם הלקוח הציע גרסה 1.2 והשרת תומך רק בגרסה 1.0 הלקוח יחזור על בקשת ההתחברות מספר פעמים לפי הצורך עם גרסאות נמוכות יותר עד ששני הצדדים מסכימים. נקודת תורפה כאן היא שלפעמים ההורדה בגרסה עלולה להתרחש שלא במכוון (מבלי שהצדדים הלגיטימיים יהיו מודעים) אם בגלל תקלה או מה שחמור יותר בשל תוקף אקטיבי שמנסה בשיטת התקפת אדם באמצע להתערב כדי להוריד את הגרסה במכוון, כך שהצדדים יתקשרו ביניהם בגרסה שנוח לו לתקוף.
התרשים משמאל מתאר את הווריאציות השונות של פרוטוקול TLS. האות S מסמלת משלוח מסרים מאומתים מצד השרת. C מסמן אימות לקוח אופציונלי. E מייצג גרסה שבה משתמשים במפתחות ארעיים של פרוטוקול שיתוף מפתח דיפי-הלמן. R פירושו חידוש שיחה. צמד המסרים ChangeCipherSpec/Finished של הלקוח והשרת מתבצעים בסדר שונה אחד מהשני, אילו של השרת נשלחים מיד לאחר ServerHello.
לפני ששרת ולקוח מתחילים לתקשר ביניהם, עליהם להסכים תחילה על סוג מערכת ההצפנה שישתמשו בה ואורך המפתחות. פרוטוקול TLS תומך במגוון רחב של אלגוריתמים והם מתחלקים לשלושה סוגים עיקריים; הצפנה, אימות והחלפת מפתחות. לצורך הצפנה TLS תומך במגוון רחב של אלגוריתמים סימטריים, למעט RC4 כולם עדיין בשימוש בדרגות שונות של ביטחון בהתאם לצורך (להלן טבלה שמכילה פירוט של האלגוריתמים). לצורך אימות TLS משתמש בשתי שיטות עיקריות HMAC ו-GOST. כאשר HMAC מגיע בשלוש גרסאות HMAC-SHA1 ו-HMAC-SHA256/384, HMAC-MD5. צופן GOST מקבל מפתח באורך 256 סיביות וגודל בלוק באורך 64 סיביות.
צופן סימטרי | גרסת פרוטוקול | Status | |||||||
---|---|---|---|---|---|---|---|---|---|
סוג | אלגוריתם | חוזק בסיביות | SSL 2.0 | SSL 3.0 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | |
צופן בלוקים עם מצב הפעלה | AES GCM | 256, 128 | לא נתמך | לא נתמך | לא נתמך | לא נתמך | בטוח | בטוח | נתמך ב-TLS 1.2 in RFCs |
AES CCM | לא נתמך | לא נתמך | לא נתמך | לא נתמך | בטוח | בטוח | |||
AES CBC | לא נתמך | לא נתמך | תלוי בשיטה | בטוח | בטוח | לא נתמך | |||
קמליה GCM | 256, 128 | לא נתמך | לא נתמך | לא נתמך | לא נתמך | בטוח | בטוח | ||
קמליה CBC | לא נתמך | לא נתמך | תלוי בשיטה | בטוח | בטוח | לא נתמך | |||
ARIA GCM | 256, 128 | לא נתמך | לא נתמך | לא נתמך | לא נתמך | בטוח | בטוח | ||
ARIA CBC | לא נתמך | לא נתמך | תלוי בשיטה | בטוח | בטוח | לא נתמך | |||
SEED CBC | 128 | לא נתמך | לא נתמך | תלוי בשיטה | בטוח | בטוח | לא נתמך | ||
3DES CBC | 112 | לא בטוח | לא בטוח | חלש | חלש | חלש | לא נתמך | ||
GOST CTR | 256 | לא נתמך | לא נתמך | בטוח | בטוח | בטוח | הוצע בטיוטת RFC | ||
IDEA CBC | 128 | לא בטוח | לא בטוח | תלוי בשיטה | בטוח | לא נתמך | לא נתמך | הוסר מ-TLS 1.2 | |
DES CBC | 56 | לא בטוח | לא בטוח | לא בטוח | לא בטוח | לא נתמך | לא נתמך | ||
40 | לא בטוח | לא בטוח | לא בטוח | לא נתמך | לא נתמך | לא נתמך | הוצא משימוש ב-TLS 1.1 ומעלה | ||
RC2 CBC | 40 | לא בטוח | לא בטוח | לא בטוח | לא נתמך | לא נתמך | לא נתמך | ||
צופן זרם | ChaCha20-Poly1305 | 256 | לא נתמך | לא נתמך | לא נתמך | לא נתמך | בטוח | בטוח | הוצע בטיוטת RFC |
RC4 | 128 | לא בטוח | לא בטוח | לא בטוח | לא בטוח | לא בטוח | לא נתמך | הוצא משימוש בכל גרסאות TLS | |
40 | לא בטוח | לא בטוח | לא בטוח | לא נתמך | לא נתמך | לא נתמך | |||
ללא הצפנה | Null | - | לא נתמך | לא בטוח | לא בטוח | לא בטוח | לא בטוח | לא בטוח | מוגדר ב-TLS 1.2 ב-RFC |
לצורך החלפת מפתחות קיימים מספר אלגוריתמים שהם וריאציות של RSA או דיפי הלמן; אלגוריתם שיתוף מפתח RSA (נקרא TLS_RSA), פרוטוקול דיפי-הלמן (TLS_DH), פרוטוקול דיפי-הלמן עם מפתח-ארעי (TLS_DHE) האות E (קיצור של Ephemeral) מייצגת מצב שבו משתמשים במפתחות אקראיים וחד-פעמיים ולא עם מפתחות קבועים, דיפי הלמן בעקום אליפטי (TLS_ECDH), דיפי הלמן עם מפתח-ארעי בעקום אליפטי (TLS_ECHE), דיפי-הלמן אנונימי (TLS_DH_anon), פרוטוקול דיפי-הלמן עם מפתח משותף מראש (TLS_PSK) ופרוטוקול אימות סיסמה בטוח (TLS_SRP). בפרוטוקול האנונימי לא מתבצע אימות לקוח או שרת כלל ולכן מטעמי ביטחון משתמשים בהם לעיתים נדירות. מתוך האלגוריתמים המנויים TLS_DHE ו-TLS_ECDHE מספקים ביטחון לפנים (forward secrecy) במובן שפריצה לא מסכנת מפתחות ששותפו בעבר. בנוסף אורך מפתחות ההצפנה יכול להשתנות בכל אחד מהאלגוריתמים המנויים מה שמרחיב את רמות הביטחון שאפשר להשיג. בעשור הקודם מקובל היה שהמפתחות יהיו באורך של לפחות 768 סיביות, בעקבות גילויים חדשים עם פרוץ פרשת סנאודן, חוקרים סבורים שהמעבר למפתחות חזקים יותר בלתי נמנע. ביולי 2013 הכריזה גוגל ששרתיה יעברו למפתחות באורך 2048 סיביות.
פרוטוקול DTLS הוא הרחבה של פרוטוקול TLS לרשת תקשורת מיתוג מנות. הפרוטוקול מעוצב כך שהוא מאפשר זרימה של הנתונים בשיטת דטא-גרם. אבל צריך להביא בחשבון סידור מחדש או איבוד חבילות. הגרסה 1.2 של פרוטוקול DTLS פורסמה ב-2012 בהצעה RFC 6347 ונועדה לעבודה עם פרוטוקול UDP. גרסת DCCP מ-2008 נקראת RFC 5238. הצעה RFC 6083 עבור פרוטוקול SCTP והצעה RFC 5764 לפרוטוקול Secure Real-time Transport Protocol.
DTLS 1.1 מבוסס על TLS 1.1 ו-DTLS 1.2 מבוסס על TLS 1.2.
דניאל בלייכנבכר פרסם ב-1998 התקפת מוצפן-נבחר כנגד SSL שנקראת "התקפת מיליון המסרים"[1]. הוא הראה שאפשר לחשוף את המפתח הסודי pre_master_secret בתוך הודעות ClientKeyExchange. הרעיון הוא שתשתית מפתח ציבורי PKCS#1 של RSA שנעשה בה שימוש כחלק מתהליך לחיצת היד, מחייבת ריפוד המסר לפני ההצפנה בהתאם לתקן. אם המסר לא מפורמט נכון מוחזרת הודעת שגיאה כך שהתוקף יכול באמצעות ניסוי וטעייה לנחש את סיביות המפתח רק מהודעות השגיאה החוזרות. ההתקפה תצליח בתנאי שניתן להבחין בהודעת Alert שנוצרה עקב פורמט RSA שגוי לבין תקלות אפשריות אחרות. הפתרון במקרה זה ברור, יש לאפשר לשרת להמשיך לבצע את תהליך לחיצת היד בשלמותו גם אם פורמט RSA שגוי ולהחזיר הודעת שגיאה כללית רק בסוף התהליך. זאת במטרה שלא לאפשר לתוקף להבחין בין סוגי השגיאות. מסיבה זו יישום נכון קריטי להבטחת אמינות הפרוטוקול וחוסנו.
התקפות ערוץ צדדי כמו התקפת תיזמון ישימות גם כנגד פרוטוקול SSL/TLS[2][3] אפילו מרחוק. אם אפשר להשיג הרבה מדידות מדויקות יחסית של פעולות השרת הקשורות למפתח הסודי, התקפה כזו עלולה להצליח. הפתרון הוא בעיקר הוספת השהיות אקראיות, מיסוך באמצעות מספרים אקראיים או קביעת משך זמן קבוע לאלגוריתם ספציפי ללא התחשבות בזמן הביצוע הדרוש בפועל.
להלן רשימה חלקית של התקפות ידועות מהתקופה האחרונה נגד פרוטוקול SSL/TLS והפתרונות שלהן.
התקפת Browser Exploit Against SSL/TLS היא "התקפת גלוי-נבחר" בשיטת אדם באמצע לניחוש מפתח השיחה, שהתגלתה ב-2011[4] על ידי תאי דואונג וג'וליאנו ריזו. השיטה מנצלת חולשה ב-SSL/TLS גרסת 1.0 שבה וקטור האתחול של חבילות מידע מוצפנות היה תוצאת הצפנה של חבילה קודמת. החוקרים הדגימו באמצעות תוכנת "רחרוח" (sniffing) וקוד JavaScript קצר איך התוקף מחלץ וקטור אתחול מהעוגיות, מזריק מידע כלשהו לבקשות מוצפנות מנסה לנחש טקסטים גלויים כלשהם ומחפש התאמה לטקסט המוצפן בית אחר בית. ההתקפה מוסתרת על ידי מיזוג ההודעות הזדוניות עם הודעות הקורבן. את קוד ה-JavaScript אפשר להסתיר בשרותי פרסום בתוך דף האינטרנט. בתוך כחצי שעה של האזנה לחיבור מוצפן עם כמות מסוימת של טקסטים מוצפנים שמקורם ידוע, התוקף יכול לפצח עוגיות מוצפנות, בקשות מוצפנות ובעצם להשתלט על השיחה. TLS בגרסאות העדכניות אינו מאפשר התקפה זו כיוון שוקטור האתחול נפרד כעת.
CRIME ראשי תיבות Compression Ratio Info-leak Made Easy היא התקפת סייבר שהתגלתה ב-2012 על ידי מפתחי BEAST, המנצלת פרצת אבטחה בעוגיות מאובטחות. כאשר ההתקפה מנוצלת להשגת עוגיות המכילות מידע של אימות זהות סודיות, היא מאפשרת למתקיף לבצע "חטיפת שיחה" על שרת אינטרנט מאובטח, המאפשרת אז לבצע התקפות נוספות. ההתקפה היא שילוב של גלוי-נבחר ודליפת מידע בתהליך הדחיסה של הרשומות. היא מסתמכת על יכולת המתקיף לראות את גודל המידע הדחוס בבתים. על ידי ניתוח שינויים בשיעור הדחיסה של טקסטים שונים שהמתקיף מנחש, אפשר ללמוד על תוכן המידע בשיטת הפרד ומשול.
התקפת Lucky 13[5] היא התקפת תיזמון נגד יישום פרוטוקול TLS ו-DTLS. היא פורסמה ב-2013 על ידי נדהם אלפרדן וקני פטרסון מ-Information Security Group at Royal Holloway אוניברסיטת לונדון. זוהי גרסה מתקדמת של התקפת אורקל ריפוד שמתמקדת בבעיה בבדיקת ה-MAC של TLS שהייתה ידועה בעבר ותוקנה מספר פעמים על ידי המפתחים ומסתבר שהיא עדיין רלוונטית. שמה נובע מהעובדה שבדיוק 13 בתים מכותר רשומת TLS נכללים בחישוב תג האימות. עיקר החולשה נובעת משיטת האימות לפי פרדיגמה "אימות ואז הצפנה" (MAC then Encrypt) ובעבר פותחו מספר התקפות מוצלחות נגד מבנה זה (ראה הצפנה מאומתת). לא כל הגרסאות של TLS ו-DTLS היו חשופות להתקפה זו אלא בעיקר גרסאות 1.0 ו-1.1 בתצורה המשתמשת במצב הפעלה CBC. וכן ההתקפה תלויה במימוש ספציפי (לטענת מיקרוסופט גרסאות התוכנה שלהם לא היו פגיעות מלכתחילה, אחרים כמו אפל עודכנו כבר בסוף 2012). בזמן פרסום ההתקפה כבר הוצאו מספר פתרונות אפשריים וחלק מהיצרנים הטמיעו את התיקון בגרסאות המעודכנות. פתרונות אפשריים הם:
[6]POODLE (ראשי תיבות של: Padding Oracle On Downgraded Legacy Encryption) היא התקפת סייבר שהתגלתה על ידי בודו מולר (Bodo Möller), ת'אי דואונג (Thai Duong) וקריסטוף קוטוויץ' (Krzysztof Kotowicz) מצוות האבטחה של חברת גוגל שדיווחו עליה בפומבי באוקטובר 2014[7]. זוהי התקפה מסוג התקפת אדם באמצע המבוססת על אורקל ריפוד נגד SSL 3.0 והיא ישימה כנגד פרוטוקול TLS בשל אופציית Fallback המאפשרת ירידה בגרסה ל-SSL. ההתקפה ניצלה 256 בקשות SSL כדי לנחש בית אחד מהמסר המוצפן. בין יתר הפתרונות האפשריים, הפתרון הטוב ביותר הוא הסרת התמיכה בגרסה SSL 3.0 הישנה, או אם זה לא אפשרי, הוספת טלאי (patch) שנקרא על ידי גוגל TLS_FALLBACK_SCSV[8]. בעקבות גילוי החולשה כל הדפדפנים המרכזיים הסירו תמיכה בגרסת הפרוטוקול[9][10][11][12].
במרץ 2015 דווחה ההתקפה FREAK קיצור של Factoring RSA Export Keys[13]. זוהי התקפת אדם באמצע שמתמקדת בתאימות גרסאות SSL. בגלל כשלים חמורים בגרסה 2 של הפרוטוקול, מתאפשר לתוקף לאלץ שימוש בגרסה מוחלשת (ישנה) מה שקרוי "שינמוך" לגרסת ייצוא של מפתח RSA בגודל 512 סיביות שאותה קל לפרק לגורמים בימינו בכוח גס על מחשב רגיל. הדרך למנוע התקפה זו היא להטמיע תבנית ייחודית מסוימת בערך האקראי המשמש לריפוד המסר בגרסה PKCS#1. בדרך זו השרת יכול להבחין בקלות בלקוח המבקש הורדה בגרסה אף על פי שהוא תומך בגרסה מתקדמת יותר.
ברשימת הצפנים של SSL נכלל מסיבות היסטוריות גם צופן RC4. ידוע שצופן זה חלש ואינו מומלץ לשימוש זה זמן רב - כשלוש עשרה שנה (מכאן השם). למרות זאת נכון לשנת 2015 השימוש בו עדיין קיים בכ-30 אחוז מתעבורת SSL בעיקר מסיבות של יעילות. בין יתר החולשות של הצופן ידוע שקיים מספר עצום של מפתחות חלשים לצופן זה, כלומר מפתחות שאם משתמשים בהם חלק מסיביות הטקסט המקורי קלות לניחוש. איציק מנטין הראה במאמר משנת 2015[14] איך אפשר לנצל חולשה זו כדי לתקוף את פרוטוקול SSL/TLS בתצורה המשתמשת בצופן RC4, לפרוץ עוגיות שיחה ואף לחטוף שיחה על ידי ניחוש סיביות מפתח. בעקבות זאת יצרני הדפדפנים המרכזיים הסירו תמיכה בצופן[15].
באוקטובר 2015 פרסמו חוקרים בארצות הברית[16], מספר בעיות באופן יישום פרוטוקול דיפי-הלמן לשיתוף מפתח הצפנה סודי, בפרוטוקול SSL/TLS ובפרוטוקולי תקשורת אחרים כמו HTTPS, SSH, IPSec וכן SMTPS, המאפשרות התקפות המסכנות את ביטחון הפרוטוקול ומאפשרות למתקיף לקרוא ולשנות מידע מוצפן העובר ברשת האינטרנט.
הפתרון המוצע הוא הגבלת אורך מפתח מינימלי ל-1024 ביט או 768 ביט למי שחושש פחות. מיקרוסופט, Tor, אפל, מוזילה וגוגל פרסמו תיקונים מתאימים לבעיה באמצעות העלאת אורך המפתח המינימלי[17]. ב-2017 פורסם RFC 8270 שהעלה את גודל המפתח המינימלי ל-2048.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.