מנגנון הפניית HSTS

טיפ ביצועים קטן שעוזר לצמצם הפניות מיותרות, טוב גם לאבטחה, ויש שיגידו שגם משמח את גוגל: HSTS: ראשי תיבות של HTTP Strict Transport Security הוא מנגנון אבטחה שמובנה בדפדפנים המוודא שברירת מחדל האתר טוענת בחיבור HTTPS מאובטח, במקום בחיבור HTTP.

תוכן עניינים

מחפשים את תוכן העניינים?
הרכיב נמצא בתחתית המסך בצד שמאל 🙂

כל לקוח שייכנס לאתר דרך קישור או בהקלדה יופנה אוטומטית לכתובת HTTPS ברמת הדפדפן (מהיר!) ולא עם הפניית שרת (איטי!)
בלי Preload – הדפדפן יזכור את ההנחייה למשך הזמן שנגדיר (אחרי הביקור הראשון באתר)
עם Preload – ההפנייה מוטמעת בדפדפן עצמו (Hardcoded) וגם ביקור ראשון יפנה ל-HTTPS.
הגישה לפניית האתר דרך HTTP תיחסם לגמרי.

הקרדיט להסברים בפוסט כמובן הולכים לדרור לימר, שיוצא לי לא מעט לקשקש איתו על ווב-פרפורמנס.

איך ליישם את המנגנון HSTS

איך ליישם HSTS לאתר שנמצא בשרת: Apache / Litespeed 

  • הוסיפו את השורה הבאה בקובץ ה-htaccess 

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;"

איך ליישם HSTS לאתר שנמצא בשרת NGINX

  • עדיף להיעזר בתמיכה של השרת. למי שיש גישה ויודע מה הוא עושה:
    בקובץ ההגדרות של NGINX (בדרך כלל /etc/nginx/nginx.conf) הוסיפו:
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;";
  • שמרו את קובץ ההגדרות של NGINX.
  • הפעילו מחדש את NGINX.

חשוב לציין כבר עכשיו: ברגע שתתבצע ההפניה, יש לדאוג שתעודת ה-SSL תהיה תקינה לכל אורך זמן פעילות האתר, אחרת לא תהיה אפשרות לגשת לאתר לא לגולשים ולא לעריכה בבק-אנד של האתר.

הסבר קצר על הפרמטרים:

max-age=31536000 – מגדיר את משך הזמן בשניות (שנה שלמה) שבו הדפדפן יזכור את ההנחיה להשתמש רק ב-HTTPS.

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

Preload – מודיע לדפדפנים לכלול את האתר ברשימת HSTS הקבועה שמובנית בקוד של הדפדפן, מה שמקצר גם את זמן הטעינה הראשוני בביקור ראשון של הגולש באתר.

חובה: לעקוב טוב טוב אחרי ההנחיות באתר: https://hstspreload.org ורק כשמוכנים ואחרי בדיקות שכל ההפניות קורות במצב תקין – לבקש הכללה ברשימת ה-Preload ולקבע את ההפניה.

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

בתמונה: הפרש הזמנים בין HSTS להפניית שרת.

דוגמה של הפרש הזמנים בין Hsts להפניית שרת
דוגמה של הפרש הזמנים בין Hsts להפניית שרת

*נ"ב: הפניות זה גרוע לביצועים. להימנע כל עוד אפשר.

יש עדיין לא מעט אתרים שגם בגוגל יש תוצאות חיפוש לקישורים שהם עדיין מקשרים להפניה מסוג: HTTP

גם שמקלידים – כל עוד אין בדפדפן הנחיית HSTS קודמת, כל הקלדה ידנית של URL של הדומיין תהיה בהתחלה הפניית HTTP ורק אז תהיה שוב הפניה איטית מהשרת לה-HTTPS.

האם הטמעת HSTS דרך קלאודפלייר תעשה את העבודה? יש לזה כפתור מובנה

Enable Hsts In Cloudflare
Enable Hsts In Cloudflare

תשובה קצרה: רבע פלסטר.

למה?

למרות שב-Cloudflare כביכול יש שרתים בישראל, בפועל בגלל כל מיני הסכמי ניתוב מסחריים בין ספקי האינטרנט, לא כל התעבורה שלהם באמת מגיעה מחוות השרתים בישראל.

לדוגמה: אני למשל גולש לאתר ישראלי שעובר דרך קלאודפלייר ומקבל את התעבורה משרתי Cloudflare בציריך 

(3 האותיות האחרונות בהדר שבצילום מסך אצלי ZRH מייצגות את נמל התעופה (!) שקרוב ביותר לשרת).

גלישה של אתר ישראלי מחובר לקלאודפלייר שמוגש מציריך
גלישה של אתר ישראלי מחובר לקלאודפלייר שמוגש מציריך

כלומר כיבכול "נפתרה" בעיה אחת (הפניה מהירה ל-HTTPS) אבל נוצרה בעיה אחרת, חמורה יותר. 

כל הבקשות עוברות דרך שרת במדינה רחוקה יותר.

כל בקשה לכל קובץ שיש.

בבסיסה, מראש הבעיה שרשת CDN אמורה לפתור: אם יש לך אתר שמשרת 150 מדינות בעולם אז רשת CDN "מקרבת" את השרתים ללקוחות שלך.

שימוש ברשת CDN לא מיועד לפתור בעיות אבטחה או בעיות מהירות.

אלו תופעות "לוואי" ובונוסים "בקטנה" ש-Cloudflare מספקים, וגם זה בתנאי שנעשו הגדרות מדויקות בהתאם. זה לא אוטומט.

זה פשוט לא הכלי הנכון.

בשביל לשים את הדברים בפרופורציות:

אם יש לך אתר תדמית סטטי עם 500 עמודים – לא נורא. כל מה שנכתב פה יחסית שולי.

אבל אם יש לך חנות איקומרס או כל אתר מורכב אחר עם אלפי עמודים ומחזורים גבוהים – כל מילי-שניה שווה כסף. כל מילי-שניה משפיעה על השורה התחתונה של העסק. וכל מילי-שניה שווה את ההשקעה.

אז לא לסמן את ה-HSTS בקלאודפלייר? זה יוריד מהירות?

אם כבר קלאודפלייר בשימוש – בטח להפעיל.
השאלה אם מההתחלה בכלל צריך קלאודפלייר?

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

בעיה מאוד נפוצה שאם תוסף המטמון לא מסונכרן עם Cloudflare דרך ה-API שלהם זה גורר רדיפה של הרבה ניקוי מטמון מיותרים… ("למה אני לא רואה את השינויי שעשיתי לפני 40 שניות???")

וגם כאמור, חלק נכבד מהגולשים מנותבים דרך שרתים באירופה וזה "פוגע" קצת במהירות.

סיכום

אם Cloudflare מוגדרת טוב (וגם יש סנכרון API לתוסף המטמון) והיא פותרת לך בעיות גדולות – ברכה.

כנראה שמשתלם לשלם את המחיר הקטן הזה של 50-150 מילי-שניות בזמן התגובה. ברמה המעשית זה יחסית שולי.

אבל, אם מדובר באתר סחר / קורסים / אתר מורכב אחר, ותחברו ל-Cloudflare על אוטומט "שיהיה" כי "זה טוב לאבטחה/מהירות/עוד דברים" בלי לטרוח אפילו להיכנס להגדרות.. שווה לחשוב על העניין.

כמו בשימוש עם כל כלי/תוסף אחר לכל דבר יש מחיר ויש תמורה.

אם אתם מעוניינים לקרוא עוד מהמידע שדרור לימר משתף, יצא לי לשבת איתו ולחלוב ממנו מידע על Font Style Matcher, כלי שמייצר CSS מותאם אישית (מותאם לעברית!) למניעת CLS כתוצאה משינוי טעינת פונטים באתרי אינטרנט

שתפו את הפוסט:

פייסבוק
וואטסאפ
לינקדאין
אי-מייל
מעוניינים לקבל עדכונים על פוסטים שאני כותב במייל? >>

היכרות עם התוסף Doubly

אם אתם מעבירים תכני פוסט או דפים בצורה ידנית, התוסף Doubly יחסוך לכם המון זמן והתעסקות עם העברה ידנית שכוללת: יצירת פוסט חדש > העברה של התכנים > יצירת תגיות וקטגוריות > הורדה והעלאה של התמונות ועוד כמה פיצ'רים שאפרט בפוסט.

לקריאת הפוסט

החשיבות של דפי 404

עמודי 404 מעולם לא מסמנים טוב באתרי אינטרנט, גוגל לא אוהבת אותם, הסירצ' קונסול שלנו (סתם זה גם של גוגל) לא אוהב אותם, מקדמי אתרים לא אוהבים אותם בכלל. עם זאת, זהו דף נורא חשוב בחוויית הגלישה של משתמש קצה (UX).

לקריאת הפוסט

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

דילוג לתוכן