(Translated by https://www.hiragana.jp/)
TLS (פרוטוקול) – ויקיפדיה לדלג לתוכן

TLS (פרוטוקול)

מתוך ויקיפדיה, האנציקלופדיה החופשית
(הופנה מהדף SSL)
פירוש נוסף ערך זה עוסק בפרוטוקול אבטחה של האינטרנט. אם התכוונתם למוסף הספרותי של הטיימס, ראו The Times Literary Supplement.

Transport Layer Security (אבטחת שכבת התעבורה; בקיצור: TLS) או גרסתו המוקדמת Secure Sockets Layer (בקיצור: SSL) הם פרוטוקולי האבטחה הפופולריים והחשובים ביותר של רשת האינטרנט. כמעט כל אתרי האינטרנט המוגנים באמצעים קריפטוגרפיים מסתמכים על פרוטוקולים המהווים חלק מהחבילה SSL/TLS. מסחר אלקטרוני, בנקאות מקוונת, דואר אלקטרוני, VoIP, מחשוב ענן ועוד. TLS נתמך על ידי מרבית הדפדפנים המודרניים.

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

בפרוטוקול תקשורת שתומך במצב מוצפן בTLS כאופציה, על הלקוח ליידע את השרת על רצונו לעבור לתקשורת מאובטחת, דרך אחת היא להשתמש בפורט ייעודי (מקובל להוסיף את האות s) שהוקצה על ידי ICANN כמו פורט 443 של HTTPS או פורטים 989/990 של FTPS. דרך אחרת היא לנצל מנגנון תלוי פרוטוקול ספציפי (כמו בקשת STARTTLS בדואר אלקטרוני) כדי לשלוח לשרת בקשה לעבור למצב של TLS.

היסטוריה של SSL

[עריכת קוד מקור | עריכה]
גרסאות
פרוטוקול שנה
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

[עריכת קוד מקור | עריכה]

פרוטוקול 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.

Transport Layer Security

[עריכת קוד מקור | עריכה]
מבנה סכמתי של פרוטוקול SSL/TLS

לפי מודל ה-OSI פרוטוקול TLS שוכן בשכבת השיחה, בין שכבת התעבורה (4) לשכבת היישום (7). בהקשר של פרוטוקולי האינטרנט המשמעות היא בטווח שבין TCP/IP ל-HTTP ,FTP, SMTP וכדומה. TLS אינו כולל מנגנון סינכרון מובנה ומסתמך על שכבת הקו שתחתיו. הפרוטוקול מתחלק לשתי שכבות עיקריות, כמתואר בתרשים.

  • שכבת לחיצת יד (Handshake layer). שמתחילה תהליך התקשרות, קובעת מספר פרמטרים משותפים כמו מספר גרסה ואלגוריתמים נתמכים (cipher suits). במהלך לחיצת היד המשתתפים משלימים תהליך אימות זהויות ומייצרים את מפתח השיחה. שכבה זו מניחה כברירת מחדל מצב "צופן NULL" שמשמעו ללא הצפנה ואימות כלל.
  • שכבת רקורד (Record layer). בשכבה זו מבוצעת חלוקת המידע העובר בקו לרשומות בגודל לכל היותר בתים. כאשר לכל רשומה צמוד תג אימות HMAC. שכבה זו תומכת בדחיסת נתונים, אם כי מסיבות של זכויות יוצרים לא מצוינת טכנולוגיה ספציפית למעט אלגוריתם NULL מנדטורי שאינו עושה דבר. בכך דחיסה הופכת לאופציה לא תיקנית תלויית מימוש.
מבנה רשומת TLS

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

  1. הצדדים מסכמים ביניהם על "חבילת צופן", ערכה של אלגוריתמים קריפטוגרפיים (וגודל מפתחות ההצפנה) שייעשה בהם שימוש לצורך הפרוטוקול.
  2. הצדדים מייצרים סוד משותף על מנת לגזור ממנו מפתחות שיחה.
  3. הצדדים מאמתים את זהותם. אף על פי ש-TLS תומך באנונימיות, אימות חד-צדדי או אימות דו-צדדי, מקובל בשלב זה לוודא רק את זהות השרת.

תמיכה בגרסאות

[עריכת קוד מקור | עריכה]

כדי לתמוך במערכות ישנות (legacy) במהלך המשא ומתן בין השרת והלקוח לפני שמתקבלת ההחלטה לגבי גרסת הפרוטוקול, ברירת המחדל היא שהלקוח מציע את הגרסה העדכנית ביותר שהוא תומך בה ואם לחיצת היד נכשלת מתחיל משא ומתן של הורדה בגרסאות (downgrade). למשל אם הלקוח הציע גרסה 1.2 והשרת תומך רק בגרסה 1.0 הלקוח יחזור על בקשת ההתחברות מספר פעמים לפי הצורך עם גרסאות נמוכות יותר עד ששני הצדדים מסכימים. נקודת תורפה כאן היא שלפעמים ההורדה בגרסה עלולה להתרחש שלא במכוון (מבלי שהצדדים הלגיטימיים יהיו מודעים) אם בגלל תקלה או מה שחמור יותר בשל תוקף אקטיבי שמנסה בשיטת התקפת אדם באמצע להתערב כדי להוריד את הגרסה במכוון, כך שהצדדים יתקשרו ביניהם בגרסה שנוח לו לתקוף.

תיאור מהלך התקשרות בסיסי

[עריכת קוד מקור | עריכה]

התרשים משמאל מתאר את הווריאציות השונות של פרוטוקול TLS. האות S מסמלת משלוח מסרים מאומתים מצד השרת. C מסמן אימות לקוח אופציונלי. E מייצג גרסה שבה משתמשים במפתחות ארעיים של פרוטוקול שיתוף מפתח דיפי-הלמן. R פירושו חידוש שיחה. צמד המסרים ChangeCipherSpec/Finished של הלקוח והשרת מתבצעים בסדר שונה אחד מהשני, אילו של השרת נשלחים מיד לאחר ServerHello.

תרשים מסרי פרוטוקול SSL/TLS
  • הלקוח פותח התקשרות על ידי משלוח בקשת ClientHello לשרת, המכילה פרטים מזהים, סוג חבילת הצופן שנתמכת על ידו וכן מספר אקראי client_random.
  • בהתאם למידע שקיבל, השרת קובע את אופן ההתקשרות - סוג חבילת הצופן, מוסיף מספר אקראי משלו server_random ושולח הודעת ServerHello בחזרה ללקוח. חילופי ההודעות נקראים "משא ומתן" (negotiation). שני המספרים האקראיים של השרת והלקוח יהוו חלק מהסוד המשותף של השיחה הנוכחית.
  • השרת מצרף כמו כן "תעודת מפתח ציבורי" (Public key certificate) תואמת X.509 המכילה את זהותו והמפתח הציבורי שלו. בדרך כלל מדובר במפתח RSA, אם התצורה כוללת פרוטוקול שיתוף מפתח מצורפת תעודת DSS שבדרך כלל נושאת מפתח ציבורי ארוך טווח של פרוטוקול דיפי-הלמן.
  • הלקוח מאמת את התעודה שקיבל מהשרת באמצעות תעודת השורש (root certificate) שבדפדפן שלו. אם קיים הבדל היררכי בין תעודת השורש שלו לבין תעודת השרת, השרת נדרש לשלוח רשימה מסודרת של כל התעודות הקשורות והלקוח יבדוק את תקפות שרשרת התעודות שקיבל עד שיתקל בתעודת השורש המובנית אצלו. בסיום שלב האימות נשלח המסר הריק ServerHelloDone.
  • הלקוח מייצר מספר אקראי חדש pre_master_secret, מצפינו באמצעות המפתח הציבורי המאומת של השרת ושולח את התוצאה המוצפנת לשרת במסר ClientKeyExchange. אם נדרש בהתאם לכינון הנוכחי, הלקוח מייצר בנוסף מפתח ארעי (Ephemeral key) לצורך פרוטוקול דיפי-הלמן. אם ברשות הצדדים מפתח ציבורי ארוך טווח של דיפי-הלמן, pre_master_secret יהיה זהה בכל התקשרות.
  • שני הצדדים גוזרים מפתח שיחה משותף בשני שלבים. תחילה משתמשים בפונקציה פסאודו-אקראית (SHA-2 לפי התקן הנוכחי) כדי לייצר ערך גיבוב מהפרמטרים: pre_master_secret, המחרוזת "master secret", המספר client_random והמספר server_random. ערך גיבוב נקרא master_secret. לאחר מכן חוזרים על פונקציית ה-PRF פעם נוספת ומייצרים ערך גיבוב מתוצאה האחרונה master_secret יחד עם הערכים; המשפט "key expansion", המספר client_random והמספר server_random. התוצאה האחרונה נקראת "בלוק מפתח". בהתאם לחבילת הצופן שנבחרה (עם או בלי אימות), בלוק המפתח מחולק לשישה מקטעים (מפתחות); שני מפתחות הצפנה, שני וקטורי אתחול ושני מפתחות אימות, כל זוג עבור הלקוח והשרת בהתאמה.
  • השרת יכול לדרוש אימות הלקוח. במקרה זה השרת שולח בקשת CertificateRequest המכילה את סוגי התעודות המותרות (כמו סוג אלגוריתם חתימה) ורשימה של רשויות מאשרות המזוהות בשמן המפורסם.
  • הלקוח מגיב בהודעת Certificate המכילה תעודת מפתח ציבורי אחת או יותר וכן תמצית (Hash) של כל חילופי המסרים מלחיצת היד, כשהיא חתומה עם המפתח הפרטי המתאים לתעודה.
  • אם פרוטוקול דיפי הלמן (DH) נבחר, אזי המפתחות הארעיים (Ephemeral keys) הציבוריים של שני הצדדים מוטמעים במסרים KeyExchange של כל אחד מהם בהתאמה. יחד עם המפתחות הפרטיים המתאימים, שני הצדדים מחלצים את הסוד המשותף pre_master_secret. אך צריך לזכור שפרוטוקול דיפי-הלמן הבסיסי אינו מספק הגנה מפני התקפת אדם באמצע.
  • שני הצדדים מסיימים את לחיצת היד על ידי שני מסרים נוספים ChangeCipherSpec המציין את המעבר לחבילת הצופן החדשה שהוחלט עליה במהלך לחיצת היד וכן הודעת Finished המציינת כי הם מוכנים לעבור למצב מוצפן ומכאן ואילך כל המסרים של שכבת הרקורד יהיו מוצפנים בהתאם.
  • במקרה של שגיאה או אימות לא מוצלח, תשלח הודעת ההתראה CloseAlert והפרוטוקול והשיחה המשויכת יסתיימו מיד.
  • הודעת חידוש מאפשרת לשני הצדדים לחדש את ההתקשרות בתהליך מקוצר. כשהשרת תומך בכך, הוא מצרף מחרוזת זיהוי שיחה להודעת 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 סיביות.

Datagram Transport Layer Security

[עריכת קוד מקור | עריכה]

פרוטוקול 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 והפתרונות שלהן.

BEAST

[עריכת קוד מקור | עריכה]

התקפת Browser Exploit Against SSL/TLS היא "התקפת גלוי-נבחר" בשיטת אדם באמצע לניחוש מפתח השיחה, שהתגלתה ב-2011[4] על ידי תאי דואונג וג'וליאנו ריזו. השיטה מנצלת חולשה ב-SSL/TLS גרסת 1.0 שבה וקטור האתחול של חבילות מידע מוצפנות היה תוצאת הצפנה של חבילה קודמת. החוקרים הדגימו באמצעות תוכנת "רחרוח" (sniffing) וקוד JavaScript קצר איך התוקף מחלץ וקטור אתחול מהעוגיות, מזריק מידע כלשהו לבקשות מוצפנות מנסה לנחש טקסטים גלויים כלשהם ומחפש התאמה לטקסט המוצפן בית אחר בית. ההתקפה מוסתרת על ידי מיזוג ההודעות הזדוניות עם הודעות הקורבן. את קוד ה-JavaScript אפשר להסתיר בשרותי פרסום בתוך דף האינטרנט. בתוך כחצי שעה של האזנה לחיבור מוצפן עם כמות מסוימת של טקסטים מוצפנים שמקורם ידוע, התוקף יכול לפצח עוגיות מוצפנות, בקשות מוצפנות ובעצם להשתלט על השיחה. TLS בגרסאות העדכניות אינו מאפשר התקפה זו כיוון שוקטור האתחול נפרד כעת.

CRIME

[עריכת קוד מקור | עריכה]

CRIME ראשי תיבות Compression Ratio Info-leak Made Easy היא התקפת סייבר שהתגלתה ב-2012 על ידי מפתחי BEAST, המנצלת פרצת אבטחה בעוגיות מאובטחות. כאשר ההתקפה מנוצלת להשגת עוגיות המכילות מידע של אימות זהות סודיות, היא מאפשרת למתקיף לבצע "חטיפת שיחה" על שרת אינטרנט מאובטח, המאפשרת אז לבצע התקפות נוספות. ההתקפה היא שילוב של גלוי-נבחר ודליפת מידע בתהליך הדחיסה של הרשומות. היא מסתמכת על יכולת המתקיף לראות את גודל המידע הדחוס בבתים. על ידי ניתוח שינויים בשיעור הדחיסה של טקסטים שונים שהמתקיף מנחש, אפשר ללמוד על תוכן המידע בשיטת הפרד ומשול.

Lucky 13

[עריכת קוד מקור | עריכה]

התקפת 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). בזמן פרסום ההתקפה כבר הוצאו מספר פתרונות אפשריים וחלק מהיצרנים הטמיעו את התיקון בגרסאות המעודכנות. פתרונות אפשריים הם:

  1. מעבר לצופן זרם RC4. אופציה לא מעשית בשל העובדה שהוא אינו בטוח כיום ולא נכלל ברשימת הצפנים המומלצים של NIST.
  2. הוספת השהיות אקראיות לתהליך ההצפנה.
  3. מעבר להצפנה מאומתת בשיטת AES-GCM.
  4. שינוי מצב הפענוח של CBC באופן שמסיר את מידע תיזמון.

POODLE

[עריכת קוד מקור | עריכה]

[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].

FREAK

[עריכת קוד מקור | עריכה]

במרץ 2015 דווחה ההתקפה FREAK קיצור של Factoring RSA Export Keys[13]. זוהי התקפת אדם באמצע שמתמקדת בתאימות גרסאות SSL. בגלל כשלים חמורים בגרסה 2 של הפרוטוקול, מתאפשר לתוקף לאלץ שימוש בגרסה מוחלשת (ישנה) מה שקרוי "שינמוך" לגרסת ייצוא של מפתח RSA בגודל 512 סיביות שאותה קל לפרק לגורמים בימינו בכוח גס על מחשב רגיל. הדרך למנוע התקפה זו היא להטמיע תבנית ייחודית מסוימת בערך האקראי המשמש לריפוד המסר בגרסה PKCS#1. בדרך זו השרת יכול להבחין בקלות בלקוח המבקש הורדה בגרסה אף על פי שהוא תומך בגרסה מתקדמת יותר.

התקפת בר מצווה

[עריכת קוד מקור | עריכה]

ברשימת הצפנים של SSL נכלל מסיבות היסטוריות גם צופן RC4. ידוע שצופן זה חלש ואינו מומלץ לשימוש זה זמן רב - כשלוש עשרה שנה (מכאן השם). למרות זאת נכון לשנת 2015 השימוש בו עדיין קיים בכ-30 אחוז מתעבורת SSL בעיקר מסיבות של יעילות. בין יתר החולשות של הצופן ידוע שקיים מספר עצום של מפתחות חלשים לצופן זה, כלומר מפתחות שאם משתמשים בהם חלק מסיביות הטקסט המקורי קלות לניחוש. איציק מנטין הראה במאמר משנת 2015[14] איך אפשר לנצל חולשה זו כדי לתקוף את פרוטוקול SSL/TLS בתצורה המשתמשת בצופן RC4, לפרוץ עוגיות שיחה ואף לחטוף שיחה על ידי ניחוש סיביות מפתח. בעקבות זאת יצרני הדפדפנים המרכזיים הסירו תמיכה בצופן[15].

Logjam

[עריכת קוד מקור | עריכה]

באוקטובר 2015 פרסמו חוקרים בארצות הברית[16], מספר בעיות באופן יישום פרוטוקול דיפי-הלמן לשיתוף מפתח הצפנה סודי, בפרוטוקול SSL/TLS ובפרוטוקולי תקשורת אחרים כמו HTTPS, SSH, IPSec וכן SMTPS, המאפשרות התקפות המסכנות את ביטחון הפרוטוקול ומאפשרות למתקיף לקרוא ולשנות מידע מוצפן העובר ברשת האינטרנט.

  1. התקפת Logjam היא מסוג התקפת אדם באמצע שבה המתקיף מבצע הורדה (downgrade) לגרסה חלשה המשתמשת במפתח 512-ביט שמקלה עליו לפרוץ את הפרוטוקול בכוח גס באמצעות מספר מרובה של מחשבים שפועלים במקביל. גרסה זו שנקראת Export-Grade היא שריד מ-1990, תקופת מגבלות ממשלת ארצות הברית על ייצוא טכנולוגיות הצפנה מחוץ לתחומיה. היא מזכירה במקצת את התקפת FREAK אך בשונה מקודמתה היא מנצלת פגם מבני בפרוטוקול ולא מתמקדת בהיבט היישום או בצופן כלשהו. ההתקפה ישימה נגד כל דפדפן מודרני שמתקשר עם שרת התומך במצב ייצוא DHE_EXPORT. כמעט 8.4 אחוז מהמיליון העליון של שמות התחומים היו פגיעים לפני שהבעיה תוקנה.
  2. בעיה נוספת נעוצה בעובדה שמליוני שרתים ברחבי העולם משתמשים במספר מצומצם של מספרים ראשוניים. בדרך כלל הם נבחרים לפי תקן מסוים כמו זה שמפורסם על ידי NIST או ISO. בעבר סברו ששיטה זו בטוחה כל עוד מייצרים מפתח אקראי חדש עבור כל שיחה. אולם השלב הראשון שהוא רובו של אלגוריתם NFS - האלגוריתם הטוב ביותר הידוע כיום לפתרון בעיית דפי-הלמן, תלוי אך ורק במספר הראשוני הזה. אם שלב זה עובר בהצלחה, המתקיף יכול להשתמש במידע שצבר כדי לפתור כל בעיית דיפי-הלמן עם ראשוני זה בקלות גם אם הפרמטרים האחרים שונים. החוקרים הדגימו עם מספר ראשוני באורך 512 ביט אותו הצליחו לשבור בתוך מספר דקות וכן העריכו שאפשר לשבור גם מערכת עם ראשוני באורך 768 ביט באמצעים מוגבלים ברמה אקדמית. ארגון ברמה בינלאומית מסוגל לפרוץ גם מפתח באורך 1024 ביט בזמן סביר. אם ההתקפה מצליחה 18 אחוז מתעבורת הרשת ניתנת לפריצה בקלות. אם פורצים כמה מספרים כאלו, כשני שלישים מ-VPN וכעשרים אחוז מתעבורת הרשת לא בטוחים. לאור החשיפות האחרונות בעקבות פרשת סנודן נראה שנתונים אלה עולים בקנה אחד עם הדיווחים לגבי הישגי ה-NSA בעשור האחרון. מהמסמכים שנחשפו עולה שהם בנו מערכת סודית שנקראת TURMOIL שאליה מעבירים בקשת התחברות IKE (החלפת מפתחות) של שרתי אינטרנט והיא אמורה להחזיר את המפתח הסודי. ההערכה היא שהם עושים זאת באמצעות אלגוריתם NFS ייתכן עם שיפורים סודיים משלהם.

הפתרון המוצע הוא הגבלת אורך מפתח מינימלי ל-1024 ביט או 768 ביט למי שחושש פחות. מיקרוסופט, Tor, אפל, מוזילה וגוגל פרסמו תיקונים מתאימים לבעיה באמצעות העלאת אורך המפתח המינימלי[17]. ב-2017 פורסם RFC 8270 שהעלה את גודל המפתח המינימלי ל-2048.

ראו גם

[עריכת קוד מקור | עריכה]

קישורים חיצוניים

[עריכת קוד מקור | עריכה]
מיזמי קרן ויקימדיה
ויקימילון ערך מילוני בוויקימילון: SSL
ויקישיתוף תמונות ומדיה בוויקישיתוף: TLS (פרוטוקול)

הערות שוליים

[עריכת קוד מקור | עריכה]
  1. ^ Bleichenbacher, Daniel (1998). "Chosen ciphertext attacks against protocols based on RSA encryption standard PKCS#1." Advances in Cryptology-CRYPTO’98, Lecture Notes in Computer Science, vol. 1462, ed. H. Krawczyk. Springer-Verlag, Berlin.
  2. ^ Brumley, David and Dan Boneh (2003). "Remote Timing Attacks are Practical." Proceedings of the 12th USENIX Security Symposium, Washington, D.C.
  3. ^ Kocher, Paul (1997). Timing Attacks on Implementations of Diffie–Hellman, RSA, DSS, and Other Systems. Advances in Cryptology—CRYPTO' 97, Lecture Notes in Computer Science, vol. 1109, ed. B.S. Kaliski Jr. Springer, Berlin, 104-113
  4. ^ עודד ירון, חוקרי אבטחה: פיצחנו את החיבור המאובטח לאתרים, באתר הארץ, 22 בספטמבר 2011
  5. ^ Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
  6. ^ This POODLE Bites: Exploiting The SSL 3.0 Fallback
  7. ^ עודד ירון, מה הקשר בין פודל, בנק הפועלים ופיירפוקס?, באתר הארץ, 13 בנובמבר 2014
  8. ^ SSL 3.0 Protocol Vulnerability and POODLE Attack, cisa.gov, ‏17 באוקטובר 2014 (באנגלית)
  9. ^ An update on SSLv3 in Chrome., groups.google.com
  10. ^ ריצ'רד בארנס, The POODLE Attack and the End of SSL 3.0, Mozilla blog, ‏14 באוקטובר 2014 (ארכיון)
  11. ^ 34.0 Firefox Release, mozilla.org, ‏1 בדצמבר 2014 (ארכיון)
  12. ^ Update turns on the setting to disable SSL 3.0 fallback for protected mode sites by default in Internet Explorer 11, support.microsoft.com, ‏2014-12-14 (ארכיון)
  13. ^ FREAK: Another day, another serious SSL security hole
  14. ^ Attacking SSL when using RC4
  15. ^ Emil Protalinski, Google, Microsoft, and Mozilla will drop RC4 encryption in Chrome, Edge, IE, and Firefox next year, VentureBeat, ‏1 בספטמבר 2015 (באנגלית) (ארכיון)
  16. ^ Weak Diffie-Hellman and the Logjam Attack
  17. ^ NSS accepts export-length DHE keys with regular DHE cipher suites, mozilla.org, ‏2 ביולי 2015 (באנגלית) (ארכיון)


סיווג פרוטוקולים על פי מודל ה־OSI
שכבת היישום HTTP • SMTP • FTP • RTP • IRC • SNMP • SIP • DNS • DHCP
שכבת הייצוג MIME • ASCII • Unicode • TLS
שכבת השיחה ASP • PPTP • SSH • NFS • RPC • SOCKS
שכבת התעבורה TCP • UDP • SCTP • DCCP
שכבת הרשת IP (IPv4 • IPv6) • ICMP • IPX • ניתוב
שכבת הקו אתרנט • Token ring • FDDI
השכבה הפיזית E1 • 10Base-T • RS-232 • DSL • SONET
אוחזר מתוך "https://he.wikipedia.org/w/index.php?title=TLS_(פרוטוקול)&oldid=39897443"