HTTP Strict Transport Security

מתוך המכלול, האנציקלופדיה היהודית
קפיצה לניווט קפיצה לחיפוש

HSTS (ר"ת של HTTP Strict Transport Security) הוא מנגנון אבטחת אתרי אינטרנט, המסייע בהגנה על אתרים מפני התקפות האדם שבאמצע, כגון מתקפות מדרגות לפרוטוקול וחטיפת עוגיות. מנגנון זה מאפשר לשרתי הרשת להצהיר כי דפדפני האינטרנט (או סוכני משתמש אחרים העומדים בתנאי הצורך) צריכים לקיים עימם אינטראקציה אוטומטית באמצעות חיבורי HTTPS בלבד, המספקים אבטחת שכבת תעבורה (TLS / SSL), בשונה מה- HTTP הלא מאובטח. HSTS הוא פרוטוקול מסלול לסטנדרטים של IETF ומצוין ב-RFC 6797.

מדיניות HSTS מועברת על ידי השרת לסוכן המשתמש באמצעות שדה כותרת תגובה של HTTPS בשם "Strict-Transport-Security". מדיניות HSTS מציינת פרק זמן שבו סוכן המשתמש צריך לגשת לשרת בצורה מאובטחת בלבד[1]. אתרי אינטרנט המשתמשים ב-HSTS לרוב אינם מקבלים HTTP, על ידי דחיית חיבורים דרך HTTP או הפניית שיטתיות של חיבורים אלו ל-HTTPS. כתוצאה מכך סוכן משתמש שאינו מסוגל לבצע TLS לא יוכל להתחבר לאתר. ההגנה חלה רק לאחר שמשתמש ביקר באתר לפחות פעם אחת, והדרך בה הגנה זו עובדת היא שמשתמש שמזין או בוחר כתובת URL לאתר שמציין http, ישדרג אוטומטית ל- https, מבלי לבצע את בקשת HTTP, אשר אינה מאובטחת.

היסטוריה

מפרט ה- HSTS פורסם כ-RFC מספר 6797 ב-19 בנובמבר 2012 לאחר שאושר ב־2 באוקטובר 2012 על ידי ה- IESG של IETF לפרסום כ-RFC מוצע. במקור היה שמו של המפרט "Strict Transport Security", אלא עם הגשתו כטיוטת אינטרנט[2] ב־17 ביוני 2010, שונה שמו ל- "HTTP Strict Transport Security", שכן המפרט חל רק על HTTP. קודם להפיכתו לטיוטת אינטרנט ומאוחר יותר לתקן רשמי, פורסם המפרט לראשונה ב-18 בספטמבר[3] 2009, ומאוחר יותר, ב-18 בדצמבר[4], פורסמה גרסת הקהילה האחרונה שלו. מאחורי כתיבת המסמך עומדים ג'ף הודג'ס, קולין ג'קסון ואדם בארת'.

צורת העבודה של הפרוטוקול

שרת מיישם מדיניות HSTS על ידי אספקת כותרת דרך חיבור HTTPS. לדוגמה, שרת יכול לשלוח כותרת כזו שבקשות עתידיות לדומיין במהלך השנה הקרובה יטופלו רק בעזרת HTTPS. כאשר יישום אינטרנט מפרסם מדיניות HSTS לסוכני משתמשים, סוכני משתמשים תואמים מתנהגים באופן הבא:

  1. הופכים אוטומטית כל קישור לא מאובטח (http) המפנה אל יישום האינטרנט לקישור מאובטח (https). למשל http://example.com/ ישונה ל- https://example.com/ לפני הגישה לשרת.
  2. אם לא ניתן להבטיח את אבטחת החיבור בעזרת HTTPS (למשל, אין תעודת TLS לשרת), סוכן המשתמש מסיים את החיבור ולא מאפשר למשתמש לגשת ליישום האינטרנט.

פגיעויות האבטחה שהפרוטוקול מונע

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

המגבלות בפרוטוקול

אם מדובר בביקור ראשון של המשתמש באתר, יכול התוקף להפשיט את כותרת ה-HSTS ממסגרת המידע ובכך לא יישמר בהגדרות סוכן המשתמש זיהוי האתר כ-HTTPS, מה שיימנע ממנו להחיל עליו את פרוטוקול ה-HSTS באותו ביקור של המשתמש. עניין זה בעייתי גם אם המשתמש נכנס לאתר בעזרת URL המכילה את HTTP ולא HTTPS בפעם הראשונה או אם כניסת המשתמש לאתר מהווה הבקשה הראשונה לאחר תקופת הפעילות שצוינה במדיניות HSTS על ידי השרת (על אתרים לקבוע תקופה של מספר ימים או חודשים בהתאם לפעילות המשתמש ולהתנהגותם). Google chrome, mozila firefox, Internet Explorer ו- Microsoft Edge מנסים להגביל את הבעיה על ידי הכללת רשימה "טעונה מראש" של אתרי HSTS, אך פתרון זה אינו יכול לכלול את כל מיליארדי האתרים ברשת האינטרנט. לבעיה זו ניתן להשיג פתרון פוטנציאלי על ידי שימוש ברשומות DNS כדי להכריז על מדיניות HSTS ולגשת אליהם באופן מאובטח באמצעות DNSSEC.

כמו כן, HSTS אינו יעיל כנגד השימוש בתחומים מזויפים: על ידי שימוש בהתקפות מבוססות DNS, ייתכן ש"התקפת אדם בתווך" יוכל להפנות את הלקוח לשרת תנועה מתחום מלאכותי שאינו מופיע ברשימת הטעינה המקדימה של HSTS, באמצעות מתקפות זיוף של DNS או יצירת דומיין שזהה כמעט לחלוטין לשם הדומיין האמיתי כמו www.example.org במקום www.example.com. כמו כן, HSTS אינו מגן מתקפות נגד TLS או ממתקפות כנגד השרת.

הערות שוליים

  1. ^ RFC 6797
  2. ^ טיוטת אינטרנט (באנגלית: Internet Draft) - טיוטת מסמכי מדיניות / מחקרים / מידע טכני המתפרסמים על ידי IETF, טיוטה זו תקפה לחצי שנה ופעמים רבות הופכת בסופו של דבר לתקן, כפי שקרה במקרה של HSTS
  3. ^ Strict Transport Security, lists.w3.org
  4. ^ Strict Transport Security, lists.w3.org
הערך באדיבות ויקיפדיה העברית, קרדיט,
רשימת התורמים
רישיון cc-by-sa 3.0

31815324HTTP Strict Transport Security

אוחזר מתוך "https://www.hamichlol.org.il/w/index.php?title=HTTP_Strict_Transport_Security&oldid=1825091"