 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
ניתוח אבטחה
ניתוח אבטחה
כפי שניתן לצפות, ל-TLS יש פחות הפרות אבטחה ידועות לעומת SSL. באופן חלקי, זה בגלל שמדובר בגירסה מחוזקת מאשר SSL, ובאופן חלקי בגלל הזמן הקצר יחסית ש-TLS בסביבה. כל פרוטוקול שמעוצב לשימוש על גבי TLS חייב להיות עדיין מעוצב בזהירות, כדי להתמודד עם כל ההתקפות האפשריות נגדו. כדאי לציין, שמידע כמו הסוג והאורך של רשומה יכול להיות נתון תחת מעקב ע"י גורמים חיצוניים. המידע לא צריך לחשוף שום דבר על תוכן המידע. לרוע המזל, החלק של המידע בפרוטוקול הוא די מוגבל, מה שגורם לתוקפים לנחש בצורה נכונה בנוגע לתוכן חבילת המידע.
ב-TLS, נדרשת בנייה כדי להרחיב את הסודות לתוך גושים של מידע, למטרת ייצור המפתח ותאריך התוקף. בכדי לגרום ל-PRF להיות מוגן ככל שניתן, יש שימוש בשני אלגוריתמי גיבוב בדרך שאמורה להבטיח את האבטחה, אם אחד מהאלגוריתמים נשאר מוגן. שני המגבבים חייבים להיות מפוצחים, לפני שתוקף יכול להשיג את המפתחות או את סודות ה-MAC כדי לסכן את סוד המאסטר.
ה-MAC של הרשומה כולל בתוכו מספר רצף כדי שההודעות החסרות, עודפות או חוזרות יתגלו.
מתי שהשרת מאומת, התקפות ה-man-in-the-middle לא מטרידות. ההפך הוא הנכון, בסשנים אנונימיים. חיבורי TSL אנונימיים לחלוטין מונעים רק האזנות וציתותים.
סוג מיוחד של התקפות man-in-the-middle יכולות להיות מושגות למרות האותנטיות. התוקף מנסה ליצור שתי ישויות שיצנחו לשיטה הכי לא מוגנת שיש לה תמיכה. ל-TSL יש תמיכה ל-SSL 2.0 מסיבות של תאימות. תוקף חכם יכול לחסום את הגישה ל-port, שירות מוגן רץ, ולכן משיג את העמיתים לנהל איתם משא ומתן בנוגע לחיבור שלא עבר אותנטיות.
SessionID נשלח מבלי שעבר הצפנה או הגנת MAC מיידית, כדי להבטיח חשאיות או אותנטיות הודעה, ולכן השרתים לא צריכים לכלול מידע חשאי במזהי סשן או לראות שמזהי סשן מזויף לא יכולים לגרום לשום נזק.
אחת מאבני הפינה של אבטחת TLS היא מייצר מספרים פסודו-אקראיים מוגן הצפנתית. ביישומים שמשתמשים ב-BSAFE או ב-RSAREF, תשומת לב נוספת צריכה להינתן בעיצוב ולדאוג שיתפקד בצורה מוגנת. הפרת אבטחה דווחה בנוגע לאלגוריתמים הללו. על פי הדיווח PRNG יסתיים במצב שבו יש תלות רק במספרים 0 או 1 אם ביטי seed במידע ה-seed.
