 תודה. ההרצאה הבאה בנושא Hacking HTTP2, New Tax on the Internet's Next Generation Foundation. יש לנו את נדב הויטל, Application Security Research Team Leader, באימפרווה, ונועם מזור באימפרווה, תהיו, לא הבנתי, אופי שובה אמצע, באימפרווה לשעבר, מציון. יש כל שעברתי, נדב מוביל את הצוות על security research, באימפרווה, נועם היה בעבר, באימפרווה, עכשיו אני מביאים שאתה סטודנט בטל אביב, לתר שני, יפה מאוד. אנחנו יכולים לדבר על Hacking HTTP2, עכשיו. אוקיי, שלום לכולם. אז כמו שאבי אמר, אנחנו הולכים, שומעים, הולכים לדבר על HTTP2, ועל התקפות חדשות ממושאים של HTTP2, אז כן, קצת על עצמנו, אז אני נדב, כמו שאבי אמר, אני מביא לצוות מחקר באימפרווה, בתחום של application security, פלוס מינוס 10 שנים, של ניסיון בעולם הזה של security, הם, קלי ההגנה, קלי תקיפה, הנועם איתי פה, הם שעה בצוות, תמכי בעיקר בתחום של vulnerable research, וכמו שאבי אמר, הם עכשיו כבר לא באימפרווה, אבל תור שני באוניברסיטה, שזה גם קבוד. עוד קרדיט, סטודנטים מהטכניון, ששתתפו איתנו בעבודה הזאת, אלכס מידניק, ועביחה קרען, זה גם להם הגיע קרדיט. אז מהעבודה שבעצם עשינו, על מה המחקר? המחקר הוא HTTP2, HTTP2 זה פרוטוקול חדש, שמתת להחליף את HTTP1, פרוטוקול תקשור את המרכזי בעולם האינטרנט. HTTP2 זה בעצם איזושהי טריטוריה החדשה ולא מוכרת, ובעצם הפרוטוקול הזה מציג כמה דברים חדשים. יש כל מיני מכניזמים חדשים שניחסו בפרוטוקול הזה, ובעקבות, כמובן שהפרוטוקול פרוטוקול חדש, יש גם מימושים חדשים, ושאנחנו באנו להסתכל על הפרוטוקול הזה, בעצם אמרנו, שאלנו את השאלה, אם גם הפרוטוקול, המימושים והמכניזמים האלו, הם פתוחים לשימוש. אז דבר ראשון, על מי בחרנו להסתכל? בחרנו להסתכל על כל הסרוברים הפופולריים היום בעולם הרייב, הפאטשי, מיקרוסופטאייס, אנג'ניקס, עוד כמה מימושים חדשים יחסית של HTTP2, NGHTP2 וג'טי, זה מימוש ג'אבה, שכמו שאפשר לראות בגרף מצד שמאל, זה בעצם, מרכיבים את רוב בעצם, רוב עולם הוויב. על מה אנחנו הולכים לדבר? אז, בטח אני אדבר קצת על המוטיבציה ועל הרקע למחקר הזה, נציג בקצרה את הטכנולוגיות המרכזיות שיש בפרוטוקול, בחלק המרכזי בעצם נועם ידבר על התקפות שמצאנו, ונסכם, הם קצת, אפשר לקחת מפרוא להמשך. אז על המוטיבציה, Http1.1, פרוטוקול שנושא, ששתחרר, ששתחרר אי שם בשנות ה-90, שלא ממש מתאים לתרים כמו שהם נראים היום. התרים דינמיים, עם הרבה מאוד ריסורסים, ריץ' קונטנט, כל התר, תכף ונראה גם בהדגמה, כל התר יש לו הרבה מאוד ריסורסים כך לטעון, דבר שמוביל כמובן לבעיות של לייטנסי, יש לנו בעיני רנטית ב-Http1.1 של head of the line, שבקשות בעצם מגיעות באופן סדרתי, יש כל מיני דרכים לפתור את הבעיה הזאתי, אבל אף אחד באמת לא הצליח לעשות זה כמו שצריך. מה שמוביל זה, שאם מגיע, בעצם כמה בקשות שמגיעות באופן סדרתי אחת אחרי השנייה, אז בעצם כל הבקשות האחרות נתקעות מאחוריה. והדרים, שזה גם בעיה ידועה, הדרים שחוזרים על עצמם, יבקשת Http1 לשנייה, כל הזמן חוזרים עוד פעם ועוד פעם, בעצם גורמים לנו לצורך הרבה יותר קו, רוחב ופס ממה שאנחנו צריכים. אוקיי, פה יש תשעי דוגמה, הם בקשה לאתר של אימפרווה, הם בקשה אחת, בעצם שנעשתה בבראוזר ומובילה למאה ה-123 שבאות אחריה, בעצם ריסורסים שניתנים בתוך עדף, שתי מגבייץ בסופו של דבר שהם הגיעים לקליאנט בשתם עשרה שניות, אוקיי, כמובן לא מצב אידאלי ובגלל זה הגיע או גם בגלל זה הגיע Http2 שמה היו בעצם קורונות קורונות הדיזיין שבאו שעשו את הפרוטוקול החדש, מה היו קורונות שרצו בעצם להביא לעולם. זו דבר ראשון, כמו שאתם כבר יכולים את הער הם נושא של מיירות להוריד את הלייטנסי ולהוריד את הבנדויף אוקיי, זה המטרה הראשונה והמוצרת עוד איזשהו קורון דיזיין שרצו לשמור עליו זה האפשרות לעשות מעבר הדרגתי לפרוטוקול הזה ואת זה הם עשו בעצם מלדי שני דברים דבר ראשון יש איזשהי אפשרות נגושי אישן פרוטוקול שהם מאפשר לך לעבור מה-HTTP-1-1 ל-HTTP-2 ובעצם הסמנטיקה, כמו שאתם יודעים ה-HTTP זה פרוטוקול טקסטואלי אז הסמנטיקה של ה-HTTP-1-1 בעצם נשמרה שזה כמובן מקל על המעבר לפרוטוקול החדש עוד איזשהו עיקרון שרצו להכניס, זה הנושא של אין קריפשן רצו שזה יהיה מנדטורי אבל דפקטור, כל הממושים שרוב דפדפנים שהם ממשים היום ה-HTTP-2, עושים את זה מעל TLS אז שנקרא דפקטור יצא שזה כן נעשה כך אוקיי, פה יש אישי עד גמה לריסור של נתן בפרוטוקול ה-HTTP-1 ואותו ריסור של נתען בפרוטוקול ה-HTTP-2 יכולים לראות את ההבדלים הגדולים וזה ככה נתן טעימה לגבי היכולות של הפרוטוקול אז מי משתמש בזה? אוקיי, הם הפרוטוקול שוחר פלוס מינוס לפני שנה וכבר אנחנו רואים שכל הסחקנים המרכזיים בעולם הרייב בעצם כבר משתמשים הפרוטוקול שזה אומר כל ההבאוזרים הגדולים Chrome, Firefox, Internet Explorer, Opera, Safari ובסרווירים כמו שאמרתי בהתחלה הם כל הרייב סרווירים שבחרנו להסתכל התערים הגדולים Facebook, Google, Twitter, YouTube כולם משתמשים כבר ב-HTTP-2 ו-CDN'ים אוקיי, CDN'ים גם כן בתור איזשהו, הם שחקן מרכזי ברשת, גם תומכים אין קפסול, עקמה, ה-Cloudflare כולם כבר תומכים בפרוטוקול החדש אוקיי, עכשיו אני אדבר קצת על הטכנולוגיות בעצם מה יש בפרוטוקול הזה אז, בגדול, אפשר להגיד שנוספו פה ארבעה מכניזמים חדשים בפרוטוקול שלא יהיו לפני זה דבר ראשון, זה משהו שנקרא Stream Multiplexing אוקיי, Stream Multiplexing זה בעצם איזשהי יכולת לשדר על בסיס TCP-Connection יחיד כמה בקשות במקביל אוקיי, אם פעם עד היינו צריכים עבור כל ריסורס לפתוח Connexion כמובן שיש לי איזה עוברת מאוד מאוד גדול ובעצם פה מנצלים איזשהי יכולת בפרוטוקול עצמו להעביר כמה בקשות ותשובות במקביל על אותו TCP-Connexion מנגנון השני זה מנגנון של Flow Control וDependency שזה איזשהו מנגנון אופטימיזציה בעצם יכולת שנותנת שנותנת גם לקליינט וגם לסרובר לשני הצדים בתקשורת לשלוט בכמות הדת האופטימלית שיכולה לעבור בחיבור וגם כמו שאמרנו יש לנו Multiplexing זאת אומרת יש לנו כמה בקשות ותשובות שרצות במקביל על אותו חיבור גם אפשר להגדיר את הדפנדנסי בין אותם בקשות אם אתה רוצה שהשרת יתפל באיזשהי בקשה בעדיפות גבוהה יותר מאשר בקשה אחרת אתה גם יכול לציין את זה בפרוטוקול וזה בעצם מאפשר שהופטימיזציה של התקשורת דבר שלישי זה מנגנון אנחנו מגעון תחיסת הידרים שמתבסס על פרוטוקול שנקרא H-Pack הזכרתי את זה בהתחלה אז יש לנו הידרים שחוזרים על עצמה מבקשה לבקשה שזה דבר שהוא מאוד בזבזני דוגמה נפוצה זה Cookies אוקיי Cookies, עוברים איתך מבקשה לבקשה ומי שמסתכל על Cookies היום יכולים לראות שרבה מאוד התארים זה איזשהו ערך אין שום סיבה בעצם לחזור ולשדר את המדע הזה כל הזמן אז משתמשים בתחיסה ומנגעון האחרון, מנגעון של סרובר פוש שזה בעצם גם כאן איזשהו שיינוי תפיסה במקום שהתקשורת תהיה מהקליאנט אלא סרובר שקליאנט מבקש ריסורסים וסרובר מחזיר לו יש לנו פה גם את האפשרות לסרובר לתחוף ריסורסים לקליאנט זאת אומרת אם אתם נגשים לעמוד הבית הסרובר יכול לדעת בצורה של קונפיגורציה בעצם כל מי שמגיע לעמוד הבית צריך לתת לו גם את האימד שחש 2.3 css וכיוצא בזה וכבר להוריד את זה לתחוף את זה לקליאנט זה נכנס לקש של הקליאנט ואז באופן כמובן הדברים הקליאנט חשות אין את עמוד הבית צריך את הריסורסים האלה ומגלה שיש לו אתם בקש ונמנת את העבורה מיותרת הזאת ואז ממה הפרוטוקול הזה USSRцу פה באיזה Pol cliff את כל ליכידות eastern הם ב lifespan היחידת ה� düş Wir gonna קליאה קטנה ביותר שיש לנו בפרוטוקול הזה זה דבר שנקרא FrameOK. זה Frame זה בעצם חלק משוכ kennen בינרית פה פה זה Frame עם זה היחידת deren היתה קטנה ביותר הם יכולים להיות לנו כל מי מסוגים של Frames דת הפרי-הדר фרי סטינגס פריית פרי Bi סוגים של הידרים, שבעצם מחברים את הפרימים האלה ביחד, אנחנו מקבלים סטרימ, אוקיי, שסטרימ זה איזשהו יחידה שמרכיבה, ריקוויסט וריספונס, אוקיי, כמה פרימים מתחברים לנו לסטרימ, סטרימ זה בעצם ייצוג של ריקוויסט וריספונס, ויש לנו הרבה סטרימים מעל קונקשן אחד, אוקיי, ואפשר לראות פה בגרף, בציור הם שסטרימים יכולים להגיע בלי קשר, ספרים יכולים להגיע מסטרימים שונים, לא תלויים אחד בשני, וזה חלק מהכוח בפרוטוקול הזה, אוקיי, שוב הם איזושהי דרך אחרת להסתכל על זה, הם עודל השחבות, אז כמו שאמרתי, TLS לא מכויב המציאות, אבל בפל רוב המימושים בוכים לעשות את זה ככה, אז מעל שכבת TLS יש לנו את השכבה הבינרית, אוקיי, הם במעלה בעצם או בתוכם מורכבת השכבה טקסטואלית, שהסינטאקס נשמר פחות או יותר, הם דומה ל-HTTP-1, אוקיי, אומנם זה עכשיו מכולק לנו לדאטה פרימז ול-הדר פרימז, אבל שמחברים את זה ביחד, ובעצם אחרי שמסמים לפרסר את המידע, זה מתרגם למשהו שהוא סמנטי מקבי ל-HTTP-1, אוקיי, הם עכשיו מנעבור לחלק השלישי, הם התקפות, ועוביר את זה לנועם. אוקיי, אז בואו ננסה לעשות את זה כיף, אז אנחנו הולכים לראות ארבעה מתקפות מניעת שירות על מימושים של הפרוטוקול, כולם היו לא ידועות כשאנחנו דיווחנו עליהם לבנדורים, וכמובן שעבדנו עם כל אחד מהבנדורים למצוא פתרון המתקפות, ולא פרסמנו אותם לפני שידענו שכל השערתים מוגנים מפני כל השערתים שבדקנו. אז מצאנו ארבעה מתקפות על ארבעה רכבים משמעותיים בפרוטוקול, בדקנו אותם על החמישה שערתים שנדב וזכיר קודם, וכל אחד מהשערתים נמצא פגיע ללפחות אחת מהמתקפות, כשהמתקפה הראשונה שנראה הפלואו-конטרול פגע באחר בשערתים, כמעט בכולם. אז בואו נעשה להבין אותה. אז הרעיון הוא שהפרוטוקול מגדיר איזשהו אובייקט שנקרא חלון, שמאפשר לכל צד בתקשורת, נניח לקוח, להגדיר לשערת, בכמה מידה הוא יכול לתפל ברגע נתון. הרעיון הוא שאם לשערת אין מספיק משאבים בשביל לקבל את, אם ללקוח אין מספיק משאבים בשביל לקבל את כל הבקשה שהוא ביקש מהשערת, הוא יכול להגיד, זה הכמות זכרון הפנויה שיש לי, השערת ישלח לו כמות מתאימה שנתונים, הוא יעקל אותה ואז הוא יכול לבקש את ההמשך שלה בקשה. כשרעינו את זה, אז חשב נעשה על התקפות, לא דת הראית, כמו שאנחנו מכירים מאיתי cp, הרעיון הוא שאנחנו יכולים לשלוח בקשה, ולא לאפשר לשערת לענות עליהם, מי שמכיר, סלוב רידזם, מתקפה מהודמה. אז בואו נראה איך אנחנו עושים את זה פה. אז הקליאנט יפתח חיבור htp2, וישלח בקשה להקטין את הגודל חלון לגודל מאוד קטן, אחר כך הוא ישלח איזושהי בקשה למשך גדול לצטרים מספר אחד. בשרף הזה, הטרדש שתיבל בבקשה בג'טי הולך לישון לשלושים שניות, בשרתים אחרים, כמו הIS והפאצ'י, צריך להמשיך להגדיל באופן איתי את החלון, בשביל להשיר את הטרד מחובר לסטרים, ובעצם לא לאפשר לו להתפנות לסטריםים אחרים או לחיבורים אחרים. עכשיו תפסנו טרד אחד של השרת, ואנחנו רוצים למנוע שירות מעל הכוחות אחרים, אז אנחנו צריכים לתפוס את כל הטרדים. מה שאינו יכולים לעשות ב htp1 זה בעצם לפתוח הרבה חיבורים במקביל, אבל פה יש לנו את האפשרות של המולטיסטפלקסים, כזה אנחנו יכולים פשוט לפתוח הרבה סטרימים. וזה מה שנעשה, וככה נתפוס את כל הטרדים שהשרת ונמנע מילה כוחות אחרים לקבל שירות. אז בואו נראה איזה קורה. אז אנחנו רואים פה במכונה אחת שאנחנו מראים את השרת, במקרה זה ה-Jetty, ממיכונה שנייה אנחנו מפעילים איזשהו קליינט לגיטימי שפשוט שולח כל כמה שניות בקשה לשרת, ומקבל דף html בתשובה. במכונה שלישית אנחנו מרצים את התוקף שלנו, ואנחנו רואים שאחי כמה שניות על הכוח הלגיטימי פשוט מפסיק לקבל תשובה. עכשיו מפסיק את התקיפה, ונראה שאחי כמה שניות, השרת מתושש ומכזיר תשובה על הכוח. אז בואו נעבור למתקפה הבאה. המתקפה הבאה היא קצת יותר מסובכת, ונעבור עליה מאוד ב-I-Level. היא תוקפת את המנגנון שה-Dependency של Http-2, שהרעיון, שהקליאנט יכול להגדיר לשרת איזשהו גרף של פלויות מן הסטרימים, בשביל להגיד לשרת איך הוא מצפה ממנו להקצות משאבים לבקשות. זה מנגנון אופטימיזציה ואפשר להתעלם ממנו, אבל הוא יכול מאוד לעזור לדוגמה אם השרת רוצה לבקש איזשהו עמוד html, ורבה תמונות, ורוצה להגיד לשרת שהוא מעדיף קודם לקבל את עמוד html, ורק אז לקבל את תמונות. יש שתי בעוד עם המנגנון הזה, אחד שהגרף חייב להיות עץ, והמימוש בהשרת בדרך כלל מסתמך הזה שזה עץ, והעניין השני הוא שלאומת מספר הסטרימים, הפתוחים שיכולים להיות במקביל, שמוגבלים בדיפות ב-Http-2, הגודל של העץ הזה לא מוגבל, מה שמאפשר לנצל את הזכרון שהשרת. ובמתקפה שמצאנו אנחנו בעצם מנצלים את העובדה השנייה בשביל ליצור מעגל בעץ ולגום לרקורס האנצופית, אז בואו נביא איך אנחנו עושים את זה. אז אנחנו יוצרים איזשהו עץ תלויות בשרת, לשפשטות אנחנו מגבילים את מספר הסטרימים שיכולים להיות פתוחים ב-Http-1 ל-4, יוצרים איזשהו עץ תלויות שממלא את כל הזיכרון שהשרת הקצה לגרף הזה, ואז מוסיפים עוד סטרימ אחד. מה שגורם לזה שהשרת ירצה למחוק עצתי מספר 7 מהעץ, עכשיו אנחנו משלח עוד בקשה, נגיד שסטרימי ספר 3 תלוי בסטרימי ספר 5, ומה שיקרה זה שסטרימי ספר 3 ירשם בזיכרון במקום שסטרימי ספר 7 היה בו קודם. עכשיו בגלל קשר והניקוי של הזיכרון, בשרת שבדקנו, הפוינטר מסטרימי ספר 7 לסטרימי ספר 5 יישאר שם, מה שיצור מעגל בעץ. יותר מאוחר שהשרת יריץ רקורסיה בשביל לסרוק את העץ הוא ייכנס לרקורס האנצופית. כאן אנחנו יכולים לראות שהכתובת בזיכרון שסטרימי ספר 7 ושסטרימי ספר 3 שהיא אותה כתובת, מה שגורם למעגל. בואו נראה את המתקפה. אז אנחנו מעלים את השרת במקרה זה NGH TTP-2 ממכונה אחרת, ומפעילים מוניטורים בשביל לראות את הסיפי ואת הזיכרון. ממכונה אחרת אנחנו מפעילים את הסקריפ של התקיפה, סקריפ פנות קצר, ועכשיו אנחנו נראה בעצם כל שורה שמותפסת על המסך זה בעצם קריאה לפונקציה הרקורסיית ואנחנו רואים שהוא לפעמים יקבל את ספר 5 ולפעמים את ספר 3, וזה כל הזמן מתחלף ביניהם. זה בעצם רקורסיה האנצופית והוא יתקק כשהוא יגיע למקסימום עומק שהרקורסיה. ב NGH TTP-2 זה מספיק בשביל להקריס את השרת. ב Apache אנחנו יכולים להקריס ככה רק סטרים 1 אז אנחנו נצטרך לחזור על הפעולה הזאת לכל סטרים בנפרד ובגלל שזה HGTP-2 שוב אנחנו יכולים לעשות את זה מחיבור TCP-1, עכשיו אנחנו רואים שהשרת בעצם קרס בסגמנטאי של פרקט. התקפה שלישית היא עליי ה-S היא הרבה יותר פשוטה וקצת עצובה, אנחנו תוקפים את המנגלון של המולטיפלייקסינג. כשהראיון הוא כשכמו שנדב וסביר שב HGTP-2 אנחנו יכולים לשלוח כמה בקשות במקביל. לעומת HGTP-1 שחיבור זה בקשה אחת או שעושים את זה באופן סיטרתי, פה אנחנו יכולים לעשות את זה במקביל, אבל כל סטרים משויח לבקשה אחת וכל בקשה משויחת לסטרים אחת. אבל זה חלוקה לוגית לגמרי ואנחנו בעצם יכולים לשלוח שתי בקשות על אותו סטרים. אז בואו ננסה לראות מה קורה כשאנחנו עושים את זה. אז זה מה שעשינו פשוט פתחנו חיבור HGTP-2 מול ה-IS שלחנו שתי בקשות על סטרים אחד וקיבלנו מסך כחול. בואו נראה את זה, כמובן שיר וזר הם לא יכולים לקבל שירות, אז זה שרת ה-IS, אנחנו ניכנס דרך דפלפן לראות שבאמת הכל עובד כמו שצריך מגניב וממכונה אחרת נראית את התקיפה, מסך כחול. התקיפה האחרונה היא על המנגנות תחיסה של HGTP-2. המנגנות תחיסה זה בעיקרון נועד להתחוס את האדרים שיכולים להיות חלק כבד בקשות. הוא עושה את זה על ידי שמירה של תבלה עם אדרים נפוצים. התבלה זה התבלה האמצעית שאנחנו רואים, היא מורכבת מחלק סטטי שקבוע לכל החיבורים ומחלק דינמי שמכיל את האדרים האחרונים שנשלחו בחיבור הספציפי הזה בכיוון מסוים. נניח שזאת הבקשה שהלקוח שאני רוצה לשלוח, היא מכילה לדוגמה מטאות גת ואיזה שהוא user-agent ואנחנו רואים שבתבלה שלנו יש בשורה מספר 2 מטאות גת, אז לקוח יכול פשוט לשלוח רפרנס לשורה מספר 2 בטבלה במקום לשלוח ממש את הידר. התבלה הדינמית מכילה את הuser-agent כי סביר להניח שהוא כבר שהלך אותו בבקשות קודמות, אז לקוח יכול לשים רפרנס לשורה מספר 62 בטבלה במקום לכתוב את כל הuser-agent שוב. אם יש עדר שלא נמצא בטבלה אפשר או לכתוב אותו בצורה מפורשת או לשים כידוד אופמן שלו. עכשיו, כמו במנגלוני תחיסה אחרים, התקיפות הדברים האלה כמו Zip Bomb ומיליון Luffatax בדרך כלל מנצלות את החוסר סימטריה, בעצם הקליינט יכול לשלוח בקשה יחסית קצרה שלא לקחמיינו הרבה משאבים, שתיפתח למשהו גדול מאוד על השרת של השרת לא יהיו מספיק משאבים בשביל להתמודד איתו. וזה מה שאנחנו נעשה, במקרה הזה אנחנו נצליח להכפיל פי 4,000 את הקמות זיכרון שהשרה צריך לעומת על הכוח. אז בואו נראה איך אנחנו עושים את זה, אנחנו פותחים איזשהו חיבורת שטיפי 2, שולחים בקשה שגורמת לאכנסה של עדר מאוד ערוך לתבלה הדינמית, ואז אנחנו פשוט שולחים כמות די קטנה של בקשות, שכל בקשה מכילה הרבה רפרנסים לאותו עדר שעכנסנו לתבלה. מה שהגרום לזה, שבקשה וגודל 14 קילו בית, אנחנו מפתח אותה ל64 מגבית. בואו נראה את המטמטיקה, אז התבלה הדינמית בדיפות מגבלת ל-4 קילו בית, אבל אנחנו יכולים להכניס עדר אחד שהם עלה את כל התבלה, ואנחנו יכולים להכניס 16 קילו בית של רפרנסים לכל בקשה. מה שאומר שבקשה אחת ששוקל את 16 קילו בית אצל הלקוח, יכולה להיפתח ל-64 מגבית אצל השרת, וה-14 בקשות כאלה יפתחו ל-896 מגבית מה שיצאינו במעבדה הספיק בשביל להקריסת, ה-NGHT-TBD. בואו נראה את התקיפה, אז מה שאנחנו רואים פה זה איזשהו מוניטורים גלה שרת, ומה שמעניין זה התאור של הזיכרון, אנחנו מפעילים את התקיפה, ורואים שהזיכרון קפץ ל-55% והמרחת עצרה, עוד כמה שניות הלקוח יקבל איזשהו ידעת שגיעה, והמרחת השתחרר, ואז הזיכרון קפוץ ל-73% והשרת לא יעמוד בזה והוא פשוט יקרוס. אז אנחנו נראה את זה עכשיו, והשרת קרס, ואנחנו יכולים לראות שוב סקמנטי של פונט. אנחנו משיכים לקבל כל הזמן על התקפות שמצאנו, התקפות דומות על מוצרים אחרים שתומכים ב-HTTP-2, אז דוגמה אחת לזה זה מה שקורה ב-Wire Shark, שבעצם שמצאנו את המתקפה האחרונה, אז רצינו לדווח עליהל למפתחים, וקלטנו קובץ תעבורת רשת, Pick Up, ושלחנו להם אותו, והם פתחו אותו ב-Wire Shark, וWire Shark קרס. מה שמסתבר זה ש-NGHTTP-D זה חלק מחבילת C שמממשת HTTP-2, קוראים לה-NGHTTP-2, והרבה מאוד מוצרים אחרים מסתמכים עליה בעצם, כמו Wire Shark, ובגלל זה אותו בגש שמצאנו בשרת, נמצא גם ו-Wire Shark וגם לקריסה. עכשיו נדר, יסביר איך להתגונן מכאל הדברים. אוקיי, תודה. אז ראינו את כל המתקפות האלו, ותחמישהי מסתכל על זה, הוא אמר אוקיי, זה לא נראה כל כך טוב. זאת מה ישראל לעשות? אז אופטיה אחת, טוב, בואו נרגיד, עזבו את ה-HTTP-2, זה לא נראה כל כך בטוח, בואו פשוט נבטר על זה. אז לא בטוח זאת הדרך נכון להתמודד עם הבעיה, כי בכל זאת הפרוטוקול הוא פרוטוקול טוב, והוא בא להחליף, הוא בא להלתת מענה לבעיות קיימות, כאילו שיש בפרוטוקול הישן. חוץ מזה, גם אם תחליטו שאתם באמת בשלב הזה, הם לא מאמצים את הפרוטוקול החדש ותבחרו, אתם יכולים לבחור איזשהו, לנסות לבחור איזשהו שרת, בפני זה, אם אתם נסו למצוא איזשהו שרת שמממש, ה-HTTP-2 בטוחה, אז כמו שנועה מראה, בעצם כל השרטים שבדקנו, היו פגיעים לפחות לאיזשהי מתקפה אחת, ואם אתם אכיתים לגמרי לבטר ה-HTTP-2 ולישר, ב-HTTP-1, אז גם אף אחד לא מבטיח לכם, שב-HTTP-1 לא היו בעיות, כמו שאתם יודעים, בוא נובר את איזם מתגלים כל יום, אז תכניות לעזוב את HTTP-2 בצד, זה פשוט לא כל כך ריאלי. אז בעצם האפשרות היחידה שנישרת לנו, זה להסתמך על פצ'ים. אוקיי, בפצ'ים זה עולם בעייתי. למה זה עולם בעייתי? יש מה שנקרא את הפצ'ינג רייס, אוקיי, עם איזשהו מונח. אני בטור בעל אפליקציה, אם אני עכשיו הולך להסטרטגיה של פצ'ינג, אז יש הרבה שאלות קשות, שאני צריך לשאול את עצמי, שלא בטוח שאני יודע את התשובות אליהם.แลא שאפשרה ראשון, איך אני יודע בך שיש איזושהי פגיעות בשרת שלי. חשן כבר באיזושהי דרך מסתורית גיליטית שיש פגיעות בשרת שלי, בנחה שלא הפרצו לאפליקציה, איך אני יודע Swift-ua אחisl approached איזושהי פתרון לבעיה הזאת. איך אני יודע, אם יש כבר פתרון עם הVendor� יצליח מצל איזושהי פתרון, איך אני יודע איך זה ישפיע על האפליקציה שלי. הם מערים במיוחד במקרים קשים, מי שזוכרת שלשוק בזמנו, הם ונדורים הוציאו תיקונים, הם חפוזים שלא בתקעו אותם מספיק ולא באמת פתרו את הבעיה, ויותר מזה שלא פתרו את הבעיה, יכול להיות שזה גם בכלל יפיל את האפליקציה שלי אז יש פה כל מיני שאלות שדק קשה להתמודד איתם, ולכן הפתרון לתענתנו הוא virtual patching אוקיי, שvirtual patching בעצם מה שאנחנו, מה שהבעל האפליקציה צריך לעשות זה בעצם להכניס עוד איזושהי קומפוננטה ברשת בין הקליינט לסרובר, קומפוננטה שיכולה להיות און פרמיס או בקלאוד, מה שרובינו קוראים web application firewall שזה איזשהו גורם ברשת שבעצם מנתרת כל התעבורה שנכנסת לאתר וברגע שמתגלה איזשהי פגיעות בשרת, אז בעצם ה-wav דוחף עדכון security לתוך הפליאנס ותוקף עכשיו שמנסה לנסל את הפגיעות הזאת, נחסם לפני שהוא מגיע לאתר מה היתרונות הברורים בגישה הזאת, דבר ראשון באה לאפליקציה לא צריך להתעסק בכלל בסקיורטי ודבר שני, גם לא צריך לעשות שינויים בכלל בסרובר, הסרובר לכאורה נשאר פגיע, אבל הוא מוגע בגלל הקומפוננטה הנוספת שעשפנו אוקיי, עכשיו סיכום, אז ראינו את http2, http2 פרוטוקול מצוין, שמורת את לנו את העתיד לתקשור את ברשת פרוטוקול שצובר פופולריות בצורה מאוד משמעותית וכמו שראינו, סובל גם מכל מיני בעיות אימפלמנטציה שנוברות בעיקר משתי סיבות. סיבה ראשונה זה הנושא של האופטימיזציה, אוקיי, הפרוטוקול הזה מאפשר כוח מאוד מאוד גדול לקליאנט לשלוט בקונקשן ובצורה שבקונקשן נעשה מולשרת וכמובן, המימושים החדשים של http2 זה כמויות גדולות מאוד מאוד של קודש ששתחררו לעולם אוקיי, צריך לזכור של http11, אז יש לו כבר את זה 20 פלוס שנה שעונים בצע בשטח שחוקרים עבדו עליו, שהקרים עבדו עליו, ידגלו שם הרבה חולשות, כל הנקודות תורפה לא יודעים כולם, אבל רובם כבר ידגלו ו http2 זה בהחלט לא המצב. אוקיי, אז יש לנו פה שילוב גם של הרבה מאוד קוד חדש שנכנס לעולם וגם של כל מיני אופציות חדשות, כשיש בפרוטוקול שנותנות הרבה מאוד כוח לקליאנט, או במקרה זה לתוקף, שזה שילוב לא מוצלך אז מה המסכנות? דבר ראשון, http2 הוא כאן והוא ישאר איתנו לעוד הרבה זמן דבר שני, שצריך לזכור, זה ש http2 עכשיו מגדיל לנו את מרחב התקיפה בצורה משמעותית יש לנו את כל המנגנים שהיא דיברנו עליהם, יש לנו קוד חדש ויש לנו בעצם עוד איזושהי טריטוריה שאף אחד או יחסית מעט נכנסו אליו וחקרו אותה לעומק בעצם העבודה שעשינו בזמנו שהרק התחלנו אותה, אז לא מצלנו שום עבודה אחרת בתחום ובגלל זה גם זה החלק מהסיבות שעשינו את העבודה הזאת דבר נוסף, זה בתור איזשהו אקוסיסטים מסתכלים על http2, אז אפשר להגיד שהוא עדיין לא סקיורתי מצ'ור, אוקיי, בדיוק מכל הסיבות שאנחנו דיברנו עליהם וגם יותר מזה, היום האתרים שמשתמשים בhtp2 עדיין לא משתמשים בכל הטכנולוגיות שהזכרנו אותם אוקיי, נגיד סרבר פוש כאילו מעט מאוד, מעט מאוד כאילו האתרים משתמשים בזה או סרברים משתמשים בזה, אוקיי, ברגע שהתחילו להשתמש עוד ועוד במנגנונים הבאמת חזקים של http2, אנחנו כנראה נגלה עוד ועוד חולשות במנגנונים האלו אוקיי, ודבר האחרון, זה בעצם מה שראינו, איך אנחנו הולכים להתמודד עם זה אז הסטרטגיה את הפאצ'ינג, זה הסטרטגיה שקשה מאוד, קשה מאוד לנצח במרוץ הזה וואף תודרסקיו, תודה, שאלות אוקיי, אני אכזור על השאלה, השאלה הייתה אם אפשר לעשות disable לחלק מהפיטשרים בפרוטוקול אז לחלק מהפיטשרים אפשר לעשות disable, חלק מהפיטשרים הם בעצם אופציונלים מה זה? כן כן, חלק מהפיטשרים הם אופציונלים, זאת אומרת, במימושים לא כל המימושים בחרו לממש את כל הדברים, לדוגמה שניסיוני לבדוק את המנגנון התלויות הם בג'טי, אז ראינו שפשוט בחרו לא לממש אותו, ובעצם להתעלם לחלוטין עם כל הטרפיק שמגיע, אז עוד שאלות