SSL

מתוך ויקיפדיה, האנציקלופדיה החופשית
קפיצה אל: ניווט, חיפוש
סיווג פרוטוקולים על פי מודל ה-OSI
שכבת יישום HTTP, SMTP, FTP, RTP, IRC, SNMP, SIP, DNS, DHCP
שכבת ייצוג MIME, ASCII, Unicode, SSL
שכבת שיחה ASP, PPTP, SSH, NFS, RPC, SOCKS
שכבת תעבורה TCP, UDP, SCTP, DCCP
שכבת רשת IP (IPv4, IPv6), ICMP, IPX , ניתוב
שכבת קו Ethernet, Token ring, FDDI
שכבה פיזית E1, 10Base-T, RS-232, DSL, SONET

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

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

בפרוטוקול תקשורת שתומך במצב SSL כאופציה, על הלקוח ליידע את השרת על רצונו לעבור לתקשורת מאובטחת, דרך אחת היא להשתמש בפורט ייעודי (מקובל להוסיף את האות s) שהוקצה על ידי ICANN כמו שער 443 של HTTPS או שערים 989/990 של FTPS. דרך אחרת היא לנצל מנגנון תלוי פרוטוקול ספציפי (כמו בקשת STARTTLS בדואר אלקטרוני) כדי לשלוח לשרת בקשה לעבור למצב של SSL/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 טיוטה

פרוטוקול 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.2 לפי RFC 5246[1] שהוצעה באוגוסט 2008. ביוני 2015 פורסמה טיוטה TLS 1.3 שטרם נכנסה לשימוש.

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

מבנה סכמתי של פרוטוקול SSL/TLS

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

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

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

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

תמיכה בגרסאות[עריכת קוד מקור | עריכה]

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

תיאור מהלך התקשרות בסיסי[עריכת קוד מקור | עריכה]

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

תרשים מסרי פרוטוקול SSL/TLS
  • הלקוח פותח התקשרות על ידי משלוח בקשת ClientHello לשרת, המכילה פרטים מזהים, סוג חבילת הצופן שנתמכת על ידו וכן מספר אקראי client_random.
  • בהתאם למידע שקיבל, השרת קובע את אופן ההתקשרות - סוג חבילת הצופן, מוסיף מספר אקראי משלו server_random ושולח הודעת ServerHello בחזרה ללקוח. חילופי ההודעות נקראים "משא ומתן" (SSL 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.

ביטחון[עריכת קוד מקור | עריכה]

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

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

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

Postscript-viewer-shaded.png ערך מורחב – התקפת ערוץ צדדי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. התקפת Logjam שהתגלתה באוקטובר 2015 על ידי צוות חוקרים בארצות הברית[12], היא מסוג התקפת אדם באמצע שבה המתקיף מבצע הורדה (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 ביט למי שחושש פחות. נגד ארגון בסדר גודל של NSA אין הרבה מה לעשות, חוץ מלקוות שהטכנולוגיה הזו לא תנוצל לרעה. בכל אופן מיקרוסופט, Tor, אפל, מוזילה וגוגל פרסמו תיקונים מתאימים לבעיה. מספטמבר 2015 התיקונים הוטמעו במרבית הדפדפנים.

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

קישורים חיצוניים[עריכת קוד מקור | עריכה]

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

  1. ^ The Transport Layer Security (TLS) Protocol Version 1.2
  2. ^ Wagner, David and Bruce Schneier (1997). Analysis of the SSL 3.0 Protocol (revised).
  3. ^ 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.
  4. ^ Brumley, David and Dan Boneh (2003). "Remote Timing Attacks are Practical." Proceedings of the 12th USENIX Security Symposium, Washington, D.C.
  5. ^ 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
  6. ^ עודד ירון, חוקרי אבטחה: פיצחנו את החיבור המאובטח לאתרים, באתר הארץ, 22 בספטמבר 2011
  7. ^ Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
  8. ^ This POODLE Bites: Exploiting The SSL 3.0 Fallback
  9. ^ עודד ירון, מה הקשר בין פודל, בנק הפועלים ופיירפוקס?, באתר הארץ, 13 בנובמבר 2014
  10. ^ FREAK: Another day, another serious SSL security hole
  11. ^ Attacking SSL when using RC4
  12. ^ Weak Diffie-Hellman and the Logjam Attack