TLS (פרוטוקול)

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

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

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

==היסטוריה של SSL==
{| class="wikitable" style="float:left; margin-left:9px;"
|-
! colspan=2 | גרסאות
|-
! פרוטוקול !! שנה
|-
| 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 המקורית נרשמה ב- למטרות היסטוריות.

==היסטוריה של TLS==

פרוטוקול TLS זהה לפרוטוקול SSL גרסה 3, למעט מספר הבדלים מינוריים, בעיקר הטיפול בקוד אימות מסרים (הוספת HMAC) ושיטת גזירת המפתח. ב-TLS מפתח השיחה הוא פונקציה פסאודו-אקראית (PRF) של תוכן סודי אקראי שנוצר על ידי שני הצדדים במשותף. כמו כן מספר אלגוריתמים קריפטוגרפיים הוכרזו כמנדטוריים כמו פרוטוקול דיפי-הלמן, DSA ו-AES. גוף התקינה IETF המליץ על TLS גרסה 1.0 ב-1999 בהצעה כשדרוג של SSL גרסה 3. ב-2006 פורסמה גרסה 1.1 ונכון לשנת 2015, הגרסה העדכנית היא TLS 1.3 לפי שתוקננה באוגוסט 2018, והחליפה את גרסה 1.2 שהוגדרה ב ב-2008.

==Transport Layer Security==
מבנה סכמתי של פרוטוקול SSL/TLS
לפי מודל ה-OSI פרוטוקול TLS שוכן בשכבת השיחה, בין שכבת התעבורה (4) לשכבת היישום (7). בהקשר של פרוטוקולי האינטרנט המשמעות היא בטווח שבין TCP/IP ל-HTTP ,FTP, SMTP וכדומה. TLS אינו כולל מנגנון סינכרון מובנה ומסתמך על שכבת הקו שתחתיו. הפרוטוקול מתחלק לשתי שכבות עיקריות, כמתואר בתרשים. 
*שכבת לחיצת יד (Handshake layer). שמתחילה תהליך התקשרות, קובעת מספר פרמטרים משותפים כמו מספר גרסה ואלגוריתמים נתמכים (cipher suits). במהלך לחיצת היד המשתתפים משלימים תהליך אימות זהויות ומייצרים את מפתח השיחה. שכבה זו מניחה כברירת מחדל מצב "צופן NULL" שמשמעו ללא הצפנה ואימות כלל.
*שכבת רקורד (Record layer). בשכבה זו מבוצעת חלוקת המידע העובר בקו לרשומות בגודל לכל היותר <math>2^{14}</math> בתים. כאשר לכל רשומה צמוד תג אימות HMAC. שכבה זו תומכת בדחיסת נתונים, אם כי מסיבות של זכויות יוצרים לא מצוינת טכנולוגיה ספציפית למעט אלגוריתם NULL מנדטורי שאינו עושה דבר. בכך דחיסה הופכת לאופציה לא תיקנית תלויית מימוש. 
מבנה רשומת TLS
בלחיצת היד משיגים שלושה יעדים: 
#הצדדים מסכמים ביניהם על "חבילת צופן", ערכה של אלגוריתמים קריפטוגרפיים (וגודל מפתחות ההצפנה) שייעשה בהם שימוש לצורך הפרוטוקול.
#הצדדים מייצרים סוד משותף על מנת לגזור ממנו מפתחות שיחה.
#הצדדים מאמתים את זהותם. אף על פי ש-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 סיביות.

{| class="wikitable" style="text-align:center"
|+רשימת צפנים נתמכים וביטחונם לפי אורך מפתח
|-
! colspan="3"| צופן סימטרי !! colspan="6"|גרסת פרוטוקול !! rowspan="2"|Status
|-
! סוג
! אלגוריתם
! חוזק בסיביות
! SSL 2.0
! SSL 3.0
! TLS 1.0
! TLS 1.1
! TLS 1.2
! TLS 1.3
|-
! rowspan="14"|צופן בלוקים עם מצב הפעלה
!AES GCM
| rowspan="3"| 256, 128
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח || rowspan="9"| נתמך ב-TLS 1.2 in RFCs
|-
!AES CCM
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח
|-
!AES CBC
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="#ffb478" | תלוי בשיטה || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח || bgcolor="LightYellow" | לא נתמך
|-
!קמליה GCM
| rowspan="2"| 256, 128
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח
|-
!קמליה CBC
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="#ffb478" | תלוי בשיטה || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח || bgcolor="LightYellow" | לא נתמך
|-
!ARIA GCM
| rowspan="2"| 256, 128
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח
|-
!ARIA CBC
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="#ffb478" | תלוי בשיטה || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח || bgcolor="LightYellow" | לא נתמך
|-
!SEED CBC
| 128
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="#ffb478" | תלוי בשיטה || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח || bgcolor="LightYellow" | לא נתמך
|-
! 3DES CBC
| 112
| bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ffdcb4" | חלש || bgcolor="#ffdcb4" | חלש || bgcolor="#ffdcb4" | חלש || bgcolor="LightYellow" | לא נתמך
|-
!GOST CTR
| 256
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח || || הוצע בטיוטת RFC
|-
!IDEA CBC
| 128
| bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ffb478" | תלוי בשיטה || bgcolor="LightGreen" | בטוח || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || rowspan="2"| הוסר מ-TLS 1.2
|-
!rowspan="2"| DES CBC
| 56
| bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך
|-
| 40
| bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || rowspan="2"| הוצא משימוש ב-TLS 1.1 ומעלה
|-
!RC2 CBC
| 40
| bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך
|-
! rowspan="3"|צופן זרם
!ChaCha20-Poly1305
| 256
| bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightGreen" | בטוח || bgcolor="LightGreen" | בטוח || הוצע בטיוטת RFC
|-
!rowspan="2"| RC4
| 128
| bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="LightYellow" | לא נתמך || rowspan="2"| הוצא משימוש בכל גרסאות TLS
|-
| 40
| bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך || bgcolor="LightYellow" | לא נתמך
|-
! ללא הצפנה
! Null
| -
| bgcolor="LightYellow" | לא נתמך || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || bgcolor="#ff8c8c" | לא בטוח || מוגדר ב-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 בהצעה ונועדה לעבודה עם פרוטוקול UDP. גרסת DCCP מ-2008 נקראת . הצעה עבור פרוטוקול SCTP והצעה לפרוטוקול Secure Real-time Transport Protocol.

DTLS 1.1 מבוסס על TLS 1.1 ו-DTLS 1.2 מבוסס על TLS 1.2.

==ביטחון==
דניאל בלייכנבכר פרסם ב-1998 התקפת מוצפן-נבחר כנגד SSL שנקראת "התקפת מיליון המסרים". הוא הראה שאפשר לחשוף את המפתח הסודי pre_master_secret בתוך <math>2^{20}</math> הודעות ClientKeyExchange. הרעיון הוא שתשתית מפתח ציבורי PKCS#1 של RSA שנעשה בה שימוש כחלק מתהליך לחיצת היד, מחייבת ריפוד המסר לפני ההצפנה בהתאם לתקן. אם המסר לא מפורמט נכון מוחזרת הודעת שגיאה כך שהתוקף יכול באמצעות ניסוי וטעייה לנחש את סיביות המפתח רק מהודעות השגיאה החוזרות. ההתקפה תצליח בתנאי שניתן להבחין בהודעת Alert שנוצרה עקב פורמט RSA שגוי לבין תקלות אפשריות אחרות. הפתרון במקרה זה ברור, יש לאפשר לשרת להמשיך לבצע את תהליך לחיצת היד בשלמותו גם אם פורמט RSA שגוי ולהחזיר הודעת שגיאה כללית רק בסוף התהליך. זאת במטרה שלא לאפשר לתוקף להבחין בין סוגי השגיאות. מסיבה זו יישום נכון קריטי להבטחת אמינות הפרוטוקול וחוסנו.

===התקפת תיזמון===

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

==התקפות==
להלן רשימה חלקית של התקפות ידועות מהתקופה האחרונה נגד פרוטוקול SSL/TLS והפתרונות שלהן.

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

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

===Lucky 13===
התקפת Lucky 13 היא התקפת תיזמון נגד יישום פרוטוקול TLS ו-DTLS. היא פורסמה ב-2013 על ידי נדהם אלפרדן וקני פטרסון מ-Information Security Group at Royal Holloway אוניברסיטת לונדון. זוהי גרסה מתקדמת של התקפת אורקל ריפוד שמתמקדת בבעיה בבדיקת ה-MAC של TLS שהייתה ידועה בעבר ותוקנה מספר פעמים על ידי המפתחים ומסתבר שהיא עדיין רלוונטית. שמה נובע מהעובדה שבדיוק 13 בתים מכותר רשומת TLS נכללים בחישוב תג האימות. עיקר החולשה נובעת משיטת האימות לפי פרדיגמה "אימות ואז הצפנה" (MAC then Encrypt) ובעבר פותחו מספר התקפות מוצלחות נגד מבנה זה (ראה הצפנה מאומתת). לא כל הגרסאות של TLS ו-DTLS היו חשופות להתקפה זו אלא בעיקר גרסאות 1.0 ו-1.1 בתצורה המשתמשת במצב הפעלה CBC. וכן ההתקפה תלויה במימוש ספציפי (לטענת מיקרוסופט גרסאות התוכנה שלהם לא היו פגיעות מלכתחילה, אחרים כמו אפל עודכנו כבר בסוף 2012). בזמן פרסום ההתקפה כבר הוצאו מספר פתרונות אפשריים וחלק מהיצרנים הטמיעו את התיקון בגרסאות המעודכנות. פתרונות אפשריים הם:
# מעבר לצופן זרם RC4. אופציה לא מעשית בשל העובדה שהוא אינו בטוח כיום ולא נכלל ברשימת הצפנים המומלצים של NIST.
# הוספת השהיות אקראיות לתהליך ההצפנה. 
# מעבר להצפנה מאומתת בשיטת AES-GCM. 
# שינוי מצב הפענוח של CBC באופן שמסיר את מידע תיזמון.

===POODLE===
POODLE (ראשי תיבות של: Padding Oracle On Downgraded Legacy Encryption) היא התקפת סייבר שהתגלתה על ידי בודו מולר (Bodo Möller), ת'אי דואונג (Thai Duong) וקריסטוף קוטוויץ' (Krzysztof Kotowicz) מצוות האבטחה של חברת גוגל שדיווחו עליה בפומבי באוקטובר 2014. זוהי התקפה מסוג התקפת אדם באמצע המבוססת על אורקל ריפוד נגד SSL 3.0 והיא ישימה כנגד פרוטוקול TLS בשל אופציית Fallback המאפשרת ירידה בגרסה ל-SSL. ההתקפה ניצלה 256 בקשות SSL כדי לנחש בית אחד מהמסר המוצפן. בין יתר הפתרונות האפשריים, הפתרון הטוב ביותר הוא הסרת התמיכה בגרסה SSL 3.0 הישנה, או אם זה לא אפשרי, הוספת טלאי (patch) שנקרא על ידי גוגל TLS_FALLBACK_SCSV<ref></ref>. בעקבות גילוי החולשה כל הדפדפנים המרכזיים הסירו תמיכה בגרסת הפרוטוקול<ref></ref><ref></ref><ref></ref><ref></ref>.

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

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

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

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

הפתרון המוצע הוא הגבלת אורך מפתח מינימלי ל-1024 ביט או 768 ביט למי שחושש פחות. מיקרוסופט, Tor, אפל, מוזילה וגוגל פרסמו תיקונים מתאימים לבעיה באמצעות העלאת אורך המפתח המינימלי<ref></ref>. ב-2017 פורסם שהעלה את גודל המפתח המינימלי ל-2048.

== ראו גם ==
* קריפטוגרפיה
* HTTPS

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

* 
* [https://www.gov.il/he/Departments/publications/reports/tls-protocol דיווח על פגיעויות במימושים שונים של TLS], באתר מערך הסייבר הלאומי.
* 
* אנציקלופדיה לקריפטוגרפיה ואבטחה

==הערות שוליים==

קטגוריה:תקנים בתקשורת מחשבים
קטגוריה:תקנים באבטחת מידע
קטגוריה:הצפנה