מסיבות שימושיות עליכם להציע הפניה מחדש ל- HTTPS מכל כתובות ה- URL של ה- HTTP. אחרת מבקרים בפעם הראשונה שמזינים example.com/some/page בסרגל ה- URL של הדפדפן יתקבלו על ידי שגיאת חיבור.

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

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

מדוע אני לא משרת סתם https בלבד?

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

התנהגות ברירת מחדל

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

לפיכך, סביר להניח שמשתמשים לא יוכלו לגשת לאתר שלך.

תאימות לאחור

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

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

אתרים רבים עדיין מקשיבים ל- HTTP אך מפנים אוטומטית ל- HTTPS ומתעלמים ממשתמשים עם באמת דפדפנים.

מישהו יכול לזייף http://www.example.com אם אני לא מגדיר HSTS?

אם תוקף רוצה לזייף את http://www.example.com , עליו להשתלט על הדומיין או להשתלט על כתובת ה- IP בצורה כלשהי.

אני מניח שהתכוונת: האם תוקף יכול לבצע התקפה של איש באמצע?

במקרה כזה כן, אבל אפילו עם HSTS או בלי:

• ללא HSTS : תוקף יכול בקלות להיות באמצע השרת שלך ולמשתמש, ולהיות פעיל (כלומר, לשנות את התוכן) או פסיבי (כלומר, האזנת סתר)

• עם HSTS : בפעם הראשונה שמשתמש מנסה לבקר באתר באמצעות HTTP, תוקף יכול להכריח את המשתמש להשתמש ב- HTTP. עם זאת, לתוקף יש חלון זמן מוגבל מתי יוכל לבצע את ההתקפה שלו.

מה עליכם לעשות?

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

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

מסקנה

זה יגרום יותר נזק מתועלת להשבית HTTP. זה לא באמת מספק יותר אבטחה.

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

פשוט בצע את ההפניה מחדש של HTTP 301 לגרסת HTTPS.

שאלות קשורות

• מדוע דפדפני ברירת המחדל הם http: ולא https: לכתובות אתרים שהוקלדו?
• מדוע האם HTTPS אינו פרוטוקול ברירת המחדל?
• מדוע אין להשתמש ב- SSL?
• מדוע אתרים מסוימים אוכפים מחסור ב- SSL ?

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

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

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

אך היזהר, הטעינה מראש היא קבועה! קשה מאוד לרדת מרשימת הטעינה המוקדמת.

כדי להיכנס לרשימת הטעינה המוקדמת: https://hstspreload.org/

אינך חייב.

לדפדפנים ומערכות הפעלה ישנות יותר (אלה בדרך כלל הולכות יד ביד) אין רשויות שורש אישור חדשות יותר, אך בדרך כלל אינן תומכות ב- HTTPS חדשות יותר. גם סטנדרטים, כך ששום דבר לא באמת אבד.

יתכן ויש לך מכשיר שאינו תומך ב- HTTPS, סקריפט מותאם אישית וכו '.

אף אחד לא יכול לזייף HTTP מכיוון שרשומת ה- DNS שייך לך ותיעוד A מצביע על כתובת ה- IP הספציפית שלך (בעולם מושלם).

אתה עושה את זה רק כדי לשמור על תאימות, זהו זה.

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

גם אם ישנם מכשירים (IoT) שניגשים לנתונים הרגישים של השרת שלך, עליך להכריח אותם להשתמש ב- TLS (התקנים קיימים רבים יכולים לאחסן את האישור שלך וליצור חיבור TLS). זכור שלגירסאות ה- SSL לפני 3.0 יש נקודות תורפה רבות כגון פודל-באג וכו '. לפיכך, השבת את כל הגרסאות הקודמות משרת האינטרנט שלך ואפשר רק> TLS 1.1.

טוב שתיישם את ה- HSTS. אני ממליץ לך לבחון את היתכנות הטמעת HPKP גם באתר שלך.

אני משתמש ב- http בנוסף ל- https לשתי מטרות:

1. הפוך את הפניית ה- http לאתר https. זה מיועד אם מישהו מקליד את שם האתר שלך לדפדפן.
2. אני יוצר אתר נפרד עבור http המיועד למישהו שינסה לגשת לאתר מבלי להשתמש בשם dot com. (משתמש אמיתי לא מתכוון לעשות זאת.) אתר אינטרנט זה יציג הודעה פשוטה בקרוב. היא גם תצרף את כתובת ה- IP שלהם לרשימת הכחשות בטבלאות IP כדי לאסור לצמיתות את אותה IP מהשרת. זה מפסיק strike> מאט האקרים המשתמשים ב masscan. (מצאתי masscan על ידי אחסון מחרוזות סוכן המשתמש של כל ה- IP שחסמתי כדי להוכיח למתכנת אחר שזה לא סריקת גוגל, אלא למעשה, האקרים זרים שעושים סריקת IP מחפשים שרתי אינטרנט כדי לנסות לפרוץ).