תהליך חיבור מאובטח ב HTTP3\QUIC

פרוטקול HTTP3 הוא כבר עובדה מוגמרת. הסיבה שאני כותב עליו היא כי רציתי להרחיב על QUIC ועל תהליך החיבור המאובטח שדפדפן ושרת שתומכים ב-HTTP3 עוברים. תהליך החיבור הזה שונה במקצת מהליך החיבור שיש ב HTTP2 ו-TLS 1.3 שעובד עם TCP ושווה להכיר אותו. פוסט זה מניח ידע בהצפנה, אלגוריתמים ואיך TLS עובד. אם אתם לא מכירים, כדאי לקרוא את הפוסט הקודם שכתבתי בנושא – הצפנה עם HTTP2\TLS 1.3.

בפוסט הזה נשתמש ב-wireshark כדי להצי�� בתנועה בין דפדפן ל-example.com שתומך ב-HTTP3. נכון לכתיבת שורות אלו, wireshark לא יודע לעבוד עם sslkeys.log כדי לקרוא את ההצפנה ב-HTTP3, אבל אני מקווה שזה ייפתר.

אז בואו ונדבר קצת על HTTP3 ו-QUIC שמבטאים אותו כמו המילה Quick ואלו לא ראשי תבות אלא שם הפרוטוקול. בגדול – פרוטוקול שנוצר בחברת גוגל על ידי ג׳ים רוסקינד בשנת 2012. רק בשנת 2021 הפרוטוקול התחיל לתפוס תאוצה אחרי שפיירפוקס וספארי החלו לתמוך בו ומועצת התקינה של האינטרנט ה-IETF יצרה לו תקן רשמי. הוא נתמך out of the box בכל הדפדפנים היום. היתרון שלו: ביצועים ואבטחה. הוא עובד עם UDP ולא עם TCP, הוא סובל הרבה פחות מ-Head-of-Line Blocking (משהו שקורה אם פקטה אחת מתעכבת או הולכת לאיבוד), הוא תומך בכמה סטרימים של מידע, כך שממש אין לו בעיה לטפל בכמה שיותר קבצים שיורדים בו זמנית ומבחינת אבטחה – הוא לא יכול לעבוד עם HTTP רגיל ותומך ב-TLS 1.2 ומעלה כאשר האבטחה באה בתוך הפרוטוקול.

הייתי יכול לחפור עוד בתיאוריה על זה, אבל כמתכנת היה לי הרבה יותר קל להבין את HTTP3 ואת QUIC מלראות אותו בעצמי, איך בדיוק? באמצעות Wireshark שמאפשר לי לראות את התנועה והפקטות ולנתח את התנועה בעצמי. בפוסט הזה אני כותב על מה שאני רואה ומזמין כל אחד גם להסתכל ולבדוק. לפעמים מבט אחד בלוג יכול לגרום לכם להבין.

אז נתחיל בהגדרת הסביבה ואז נראה.

בדיקה שכרום עובד עם QUIC והפעלת כרום שיגלה מפתח הצפנה סימטרי

השלב הראשון הוא לוודא שכרום תומך ב-QUIC. נכנסים אל chrome://flags ומחפשים QUIC. מוודאים שהוא enabled. זו ברירת מחדל אבל בפוסט הקודם עשינו לזה disable – אז אם עקבתם אחר הפוסט הקודם, זה הזמן להחזיר עטרה ליושנה:

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

export SSLKEYLOGFILE=~/Documents/sslkeys.log && open -na "Google Chrome" --args --incognito

ובחלונות

set SSLKEYLOGFILE=%USERPROFILE%\Documents\sslkeys.log
start chrome --incognito

זה יוצר קובץ שאליו כרום מייצא את המפתחות הסימטריים ופותח כרום במצב אינקוגניטו שמחובר אליו. מצב האינקוגניטו נועד לוודא שיש חילופי מפתחות ואין מפתחות ב-cache או משהו בסגנון.

הפעלת Wireshark

נפתח את כלי המפתחים, נתחיל את ההקלטה של Wireshark ונכנס בשמחה ובששון אל example.com! הוא לא תמיד עובד מאותו IP (זה קצת שיגע אותי בהתחלה) אז כדאי לבדוק עם כלי המפתחים עם איזה כתובת IP הוא עובד.

השלב הבא הוא להכניס פילטר ל-Wireshark. נכניס גם את כתובת ה-IP של example.com וגם את QUIC:

ip.addr == 96.7.128.198 && quic

זהו! יש לוג! עכשיו אפשר להסתכל מה קורה ואפשר להתחיל בניתוח.

ניתוח של תנועת QUIC ותחילת ל��יצת היד הקריפטוגרפית

אז חשוב להבין שמבחינת TLS זה אותו TLS. גם QUIC תומך בחילופי מפתחות ובעצם מטמיע ומשתמש ב-TLS 1.3. אבל בניגוד ל-TLS ב-HTTP2 שיושב על ה-TCP. במאמר הקודם ראינו איך יש בעצם פקטת מידע שהמידע של ה-TLS רוכב עליה, פה ה-QUIC יושב ממש בפנים. ה-handshake של TLS 1.3 מועבר בתוך QUIC ב-CRYPTO frames, לא "רוכב" מעל פרוטוקול אחר.

ב-Wireshark רואים את זה מעולה. למשל בחיבור של http אנו רואים:

Ethernet → IP → TCP → TLS באופן יפה ומסודר

אבל בחיבור של QUIC – וואי וואי וואי וואי זה נראה כמו חפלה משוגעת! אין סדר. יש את ה-UDP ואז את QUIC שיש בו פריים CRYPTO ורק בתוכו יש את ה-TLS!

הצעד הראשון – Handshake

מה שמעניין מאד בבקשה הראשונה הזו , היא שימו לב שבפקטה הזו חסרים דברים! ה-WireShark באדיבותו אומר שזה נקטע וממשיך בפקטה הבאה. ב-TCP אנחנו רגילים ש-Wireshark מסדר לנו את הכל אבל פה כל הודעה עומדת ברשות עצמה.

ואכן, יש פקטה נוספת. הקודמת היתה עם PKN 1 והשניה עם PKN 2. הגודל פה הוא 1200 בייטים (מינימום, כדי למנוע Amplification attacks – כלומר שליחת בקשות קטנות מאד כדי להעמיס על השרת) עד 1500 בייטים.

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

השרת שולח ACK

מה התגובה? ACK שזה אומר ״קיבלתי״. בבקשה הוא אומר כמה פקטות הוא קיבל. זה הפלט שיש בצילום המסך ומעניין אתכם:

ACK
    Frame Type: ACK (0x0000000000000002)
    Largest Acknowledged: 2
    ACK Delay: 142
    ACK Range Count: 0
    First ACK Range: 1

קיבלתי 2 פקטות מ-0 ועד 1. זה פרוטוקול UDP, אין למי ששולח, במקרה הזה הקליינט, מושג אם מה שהוא שלח התקבל בכלל. אז השרת נותן אינדיקציה.

השרת שולח מידע קריפטוגרפי על עצמו

בנוסף ובמקביל, הוא משגר את לחיצת היד שלו בפרוטוקול TLS 1.3. גם פה חבילה אחת לא מספיקה. נשלחות PKN 3,4,5 בנוסף ל-2 שנשלחה עכשיו ו-1 שהיא ה-ACK. שם יש את כל המידע של ה-TLS.

הקליינט שולח ACK

השלב הבא, כפי שניחשתם, זה שהקליינט ישלח בתגובה לשרת ACK – קיבלתי את כל הפקטות שלך. הנה מה שמופיע בצילום המסך:

ACK
    Frame Type: ACK (0x0000000000000002)
    Largest Acknowledged: 4
    ACK Delay: 0
    ACK Range Count: 0
    First ACK Range: 1

לא נדיר לראות בקשת ACK שנשלחת פעם שניה, כאמור זה UDP – אם אין אישור לא ממתינים למצוא את הפקטה הנעלמת, שולחים אותה שוב (עם תיקון קל ב-ACK כי שלחנו עוד פקטה). זה השלב שבו הקליינט לוקח את החתימה ומוודא אותה. בדיוק כמו שכתבתי ופירטתי בפוסט הקודם. זה אותו TLS 1.3 ב-ד-י-ו-ק. לא המצאות חדשות. אבל בפרוטוקול אחר.

הקליינט שולח verified data והתהליך מסתיים

הקליינט אחרי בקשת ה-ACK שולח verify data – שזה השלב הסופי. השרת יכול לבדוק את החתימה כדי לוודא שהמפתח הסימטרי עובד כמו שצריך.

לחיצת היד הקריפטוגרפית הושלמה, אנו נראה עכשיו תנועה של HTTP3. יש חילופי מפתחות סימטריים.

ֿשימו לב איך העניין של ה-TLS הפך לפשוט יחסית. לא מבחינת תהליך כי זה אותו תהליך, אלא מבחינת המידע וזרימתו. קודם נוצר חיבור TCP ועליו נוצר ה-TLS. פה הוא נוצר ממש עם החיבור ועובר עם ה-UDP.

סיכום

אני נהניתי מאד להציץ לתוך הקרביים של HTTP3 ולראות את ה-TLS 1.3 עובד שם וגם לראות איך הפרוטקול עובד מהר, אפילו ברזולוציה של example.com המסכן ודל התוכן. תמיד מעניין ממש לראות בעיניים דברים כאלו. נכון, זה לא משהו שעושים בעבודה היומיומית אבל כשמגיע באג בתקשורת או באבטחה – תאמינו לי שידע כללי כזה מאד עוזר. במיוחד בעידן של LLM שיזרוק עליכם ערימה של מידע ויכול להביא אתכם לכל מיני בורות – לפעמים הידע הזה בדיוק הוא זה שיציל אתכם. אבל גם בלי התועלת המעשית – זה ממש מעניין!