שיתוף מפתח TLS מול תעודת לקוח: מה מהשניים מבצע התחברות?
הפרידו בין הסכם המפתח ובין אימות הלקוח וזהות היישום, וקראו את הודעות לחיצת היד שמראות מה מהשניים החיבור השתמש בו בפועל.
נשיאת ערך החלפת מפתח ציבורי בלחיצת יד אינה אותו אירוע כמו לקוח שמתחבר. האחד קובע מצב קריפטוגרפי עבור החיבור; האחר מציין מי הוא הלקוח, והוא מתרחש רק כאשר השרת מבקש זאת וההחלפה תומכת בכך. התייחסות לראשון כאל השני מובילה למסקנות שגויות לגבי מה ש־VPN מסתיר ומה שאינו מסתיר. קראו את ההודעות, ואחר כך החליטו איזה מארבעה מאפיינים באמת נצפה.
שני אובייקטים שנראים דומה ביירוט
לקוח TLS 1.3 יכול לתרום חומר החלפת מפתח בטיסתו הראשונה בלי להציג תעודה כלשהי. תרומה זו ציבורית מלכתחילה, משום שהשרת זקוק לה כדי לגזור את הסוד המשותף. תעודת לקוח היא הודעה אחרת, והיא נשלחת רק לאחר שהשרת ביקש תעודה. היא נושאת זהות שהשרת מאמת לאחר מכן, ואימות הדדי הוא החלטה של השרת ולא תכונה שחבילת ההצפנה מחייבת. זהות היישום היא דבר שלישי לגמרי: טופס התחברות, אסימון נושא, עוגייה. שום דבר מזה אינו מופיע בלחיצת היד, וכולם שורדים שינוי בנתיב הרשת.
| Object in play | What it establishes |
|---|---|
| Key-exchange share | Cryptographic state for this connection |
| Server certificate | Which server the client reached |
| Client certificate | Client authentication, when requested |
| Application session | Account identity inside the application |
ארבע השורות עצמאיות. חיבור יכול לכלול את השורה הראשונה והשנייה, לדלג על השלישית, ועדיין לשאת את הרביעית בכותרת עוגייה.
החליטו מה לחיצת יד מיורטת יכולה להוכיח
מלחיצת היד לבדה הצופה לומד את הגרסה שנוהלה, את חבילת ההצפנה, את תעודת השרת ואת ערכי החלפת המפתח הציבוריים. זה מספיק כדי לקחת טביעת אצבע של מימוש לקוח וכדי לראות לאיזה שרת נוצר קשר. מה שהיא אינה מספקת הוא המצב הפרטי הדרוש לפענוח החיבור, שסודיותו נשענת על ההחלפה האפמרלית ולא על החלק הציבורי. היא גם אינה מספקת זהות חשבון, שמעולם לא הייתה בלחיצת היד מלכתחילה.
לכן המסקנה הכנה צרה: בהחלפה זו לא הוצגה תעודת לקוח. אין הכוונה שהלקוח לא שלח דבר שניתן לקשר, ובוודאי לא שהפעלה לא נשאה מזהה כלשהו.
קראו את ההודעות ולא את שם הצופן
שאלו את השרת מה הוא מבקש, במקום להסיק מחבילת ההצפנה. לחיצת יד של TLS 1.3 הכוללת בקשת תעודה נראית בתמליל, והיעדרה נראה באותה מידה.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'אחר כך חזרו על הפעולה עם תעודת לקוח מוגדרת, והשוו. הריצה השנייה אמורה להראות שהתעודה נשלחת ומתקבלת; הראשונה לא אמורה להראות דבר, וזהו ההבדל הממשי שעליו הוויכוח.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quietאם אתם צריכים רק את מקרה הגלישה הרגיל, הפלט המפורט של הלקוח מספיק כדי לראות את גרסת הפרוטוקול, את תוצאת האימות ואם הוצעה תעודת לקוח. שרת שלעולם אינו שולח בקשת תעודה לא יכול היה לקבל אחת.
היכן החידוש משנה את התשובה
חידוש ב־TLS 1.3 משתמש בכרטיסים הקשורים למצב סודי, כך שחיבור מאוחר יותר יכול להסתיים בלי החלפת תעודות מלאה. זה מפחית את מה שצופה רואה ומשנה את מה שהתמליל מוכיח. הוא אינו יוצר זהות במקום שבו לא הייתה. הפעלה מחודשת עדיין שייכת לאותה הפעלת יישום, וכל עוגייה או אסימון בה נשארים המזהה החשוב.
זו הסיבה שסקירת פרטיות שנעצרת ב"אין תעודת לקוח" מחמיצה את החלק המעניין. השאלה שצריך לשאול היא איזה צד מחזיק במזהה יציב, ולא איזו הודעה הייתה חסרה בלחיצת יד אחת.
רשמו ארבעה מאפיינים, לא פסק דין אחד
רשמו את הסכם המפתח, אימות השרת, אימות הלקוח וזהות היישום כארבעה שורות נפרדות, עם הראיה לכל אחת. מלאי זה שורד שינויי גרסת פרוטוקול, והוא הופך טענה על פרטיות לברת בדיקה בידי אחר. אחר כך הוסיפו מה שנתיב הרשת תורם. VPN משנה את כתובת המקור שהשירות רואה; הוא אינו מסיר התחברות, עוגייה או טביעת אצבע של מכשיר שכבר נמצאים בידי היישום.
רשמו יחד את הגרסה שנוהלה של החיבור ואת תוצאת בקשת התעודה, משום שזהו הצמד שסוקר זקוק לו כדי לשחזר את מסקנתכם בלי יירוט משלו.