שאלה האם זה רע להפנות http ל- https?


אני פשוט התקין תעודת SSL בשרת שלי.

לאחר מכן הוא מגדיר כתובת אתר להפניה מחדש עבור כל התנועה בדומיין שלי בפורט 80 כדי להפנות אותו ליציאה 443.

במילים אחרות, כל שלי http://example.com התנועה מנותבת כעת למכשיר המתאים https://example.com גרסה של הדף.

ההפניה נעשית Apache שלי Virtual Hosts קובץ עם משהו כזה ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

השאלה שלי היא, האם יש חסרונות כלשהם באמצעות SSL?

מאז זה לא 301 הפניה, אני מאבד הקישור מיץ / הדירוג במנועי החיפוש על ידי מעבר ל https?

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


גיליון עדכני

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

enter image description here 


245
2018-01-28 00:12




[WTF - אני לא יכול להוסיף תשובה (אם כי נראה שיש לי מספיק נציג).] התשובה שלי תהיה (בין השאר) זה לפעמים זה רע. שקול להעביר מפתח COOKIE או API ב- GET over HTTP. אם האתר שלך מפנה מחדש בקשות HTTP לבקשות HTTPS, שיחות אלה יפעלו, אך המפתח COOKIE או ה- API יועבר בחשוף. חלק ממשתמשי ה- API מפסיקים את HTTP, גישה חזקה יותר - ללא HTTP כלל, כך שאינך יכול אפילו להפעיל אותו, אלא אם תשתמש ב- HTTPS. דוגמה: "כל בקשות ה- API חייבות להיות מבוצעות באמצעות HTTPS, שיבוצעו שיחות שבוצעו באמצעות HTTP רגיל" סטריפ / docs/api? lang=php#authentication - codingoutloud
@codingoutloud - החלופה היא כי כל הדבר קורה על HTTP ללא HTTPS כלל. איך זה יותר טוב? - Mark Henderson♦
@BenCrowell, זה בגלל א פורטל שבוי נראה נורא כמו sslstripהתקפה בסגנון להפנות מחדש (הם שניהם אדם- in-the- באמצע חטיפות בקשה) כך HSTSהדפדפנים יוצגו את שניהם. - Jeffrey Hantin
להיות מודע לכך שהשימוש ב- https פירושו שכל מה שתכלול צריך להיות גם https או שהוא לא נטען - לדוגמה, טעינת jquery src="://example.com/jquery.js" - שים לב חוסר http או https כך הדפדפן טוען את המתאים. היה לי סיוט מנסה לקבל קצת אמזון דברים מוטבע לטעון כראוי כמו ה- API (נטען באמצעות https) הפיק קישורים http - כלומר הם לא עבדו כראוי עד שמצאתי את הפרמטר מתועד כדי לעבור קישורים https - Basic
ג'ייסון; העדכון שלך צריך להיות שאלה חדשה, כנראה ב מנהלי אתרים כפי שהוא לא קשור (טכנית) לשאלה המקורית שלך. אבל זה כנראה כי גיליונות הסגנון שלך מגיעים מתוך תחום לא מאובטח. - Mark Henderson♦


תשובות:


ה [R] דגל בכוחות עצמו הוא 302 ניתוב מחדש (Moved Temporarily). אם אתה באמת רוצה שאנשים משתמשים בגרסת HTTPS של האתר שלך (רמז: אתה עושה), אז אתה צריך להשתמש [R=301] עבור הפניה מחדש קבועה:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

א 301 שומר את כל Google-fu ו- pageranks הרווחת קשה ללא שינוי. לוודא mod_rewrite מאופשר:

a2enmod rewrite

כדי לענות על השאלה המדויקת שלך:

האם זה רע להפנות http ל- https?

ממש לא. זה טוב מאוד.


309
2018-01-28 00:27



תודה על המידע, הבוס שלי אומר לי את הסיבה שהוא רק מפעיל https על דפים מסוימים של האתר שלו, היא כי היא משתמשת הרבה יותר משאבי שרת כדי להפעיל אותו על כל דף. אתה יודע משהו על זה או אם זה נכון? - JasonDavis
@jasondavis רק אם אתה לא מבלה כמה דקות לייעל אותו. - Michael Hampton♦
"הוא משתמש במשאבי שרת רבים יותר כדי להפעיל אותו בכל עמוד". מעבדים מודרניים יש תכונות האצת ההצפנה שהופכים SSL כמעט בחינם. אל תדאג תקורה. - Adam Davis
@AdamDavis האלגוריתם הצפנה עשוי להיות קל, אבל לחיצת היד עדיין קיים. כמו כן, HTTPS מונע מ- HTTP פרוקסי לשמור במטמון את התוכן שלך. ב רוב במקרים, תקורה של HTTPS היא מינימלית וכדאית, אבל להיות זהיר לגבי הכללה יתר. - 200_success
זה הורג במטמון משותף, שהוא שימושי עבור כמה דפוסי השימוש של האתר, ולעתים קרובות מגנה מעט (האם זה חשוב שאנשים יכולים לדעת שאתה ביקר באתר, אבל לא את הפרטים של מה שעשית? זה המצב היחיד שבו SSL הוא שימושי). היתרון העיקרי של SSL על כל משאב הוא לא שאתה צריך "מאובטח" למשל. אנשים מסתכלים על "עלינו", אבל אתה לא יכול להחליק למעלה ולא מצליחים להשתמש בו במקרה שבו אתה צריך. - Jon Hanna


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

  1. בדוק את האתר כולו עבור קישורים פנימיים וודא שהם משתמשים ב- HTTPS אם אתה מציין את שם הדומיין שלך בקישורים, לכן אינך גורם להפניות משלך.
  2. עדכן את <meta property="og:url" כדי להשתמש בגרסת https של הדומיין שלך.
  3. אם אתה משתמש <base href= שוב עדכון כדי להשתמש HTTPS.
  4. להתקין פרוטוקול SPDY אם אפשר
  5. הקפד להשתמש Sprites תמונה CSS במידת האפשר, כדי לצמצם את מספר הבקשה.
  6. עדכן את קובצי ה- Sitemap כדי לציין את סטטוס ה- https, ולכן עכבישים לאורך זמן לומדים את השינוי הזה.
  7. שנה העדפות מנוע חיפוש כגון Google Webmaster Tools כדי להעדיף HTTPS
  8. איפה אפשר לטעון את כל התקשורת stactic שרתי HTTPS CDN.

אם הנ"ל הוא פנה, אז אני בספק אם יהיו לך בעיות רבות.


49
2018-01-28 02:08



SPDY היא הצעה טובה; יש אפילו נראה מודול הוספת תמיכה SPDY ל Apache 2.x. - Calrion
באמצעות "//yourserver.com/some-uri" במקום "yourerver.com/some-uri"פותר את הבעיה (1) משום שהדפדפן יבחר את הסכימה המתאימה (http או https) בהתאם לסכימה שבה נטען הדף. - MauganRa
@MauganRa אלא אם כן, כמובן, זה קישור מ דף המאמר http כדי https דף הכניסה, למשל. - Mołot
Google רואה את כתובת האתר שמישהו מבקר באמצעותה Referer כותרת. לדוגמה, אתר זה משתמש ב- jQuery מה- CDN של Google והדפדפן שלי שולח בקשה ל- Google בכל פעם שאני טוען מחדש את האתר. כך א Referer כותרת היא גם לשלוח אל Google אשר מוגדר לכתובת של אתר זה. כך ש- Google יכולה לעקוב אחר האתרים שבהם אני מבקר במהלך הזמן שבו כתובת ה- IP שלי אינה משתנה (ואם אני משתמש בשירות Google במהלך הזמן הזה, Google יכולה גם לחבר את המידע הזה לחשבון Google שלי). - Stephan Kulla
עבור 1) אני פשוט עשה חיפוש ולהחליף במסד הנתונים MySQL שלי http ל https ... אני משתמש וורדפרס אז זה עשה את זה ממש קל לעדכן מאות קישורים - JasonDavis


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

לגבי ניתוב מחדש מ http ל https התשובה היא לא כל כך פשוט.

ניתוב מחדש יעשה את זה הרבה יותר קל עבור המשתמשים שלך, הם פשוט להקליד whateversite.com ו מנותב מחדש ל- https.

אבל. מה אם המשתמש נמצא לפעמים ברשת לא מאובטחת (או קרוב אליה טרוי האנט והאננס שלו) לאחר מכן המשתמש יבקש http://whateversite.com מתוך הרגל ישן. כלומר http. זה יכול להיות בסכנה. ניתן להפנות את כתובת האתר להפניה מחדש https://whateversite.com.some.infrastructure.long.strange.url.hacker.org. למשתמש רגיל זה ייראה לגיטימי למדי. אבל את התנועה ניתן ליירט.

אז יש לנו שתי דרישות מתחרות כאן: כדי להיות ידידותי למשתמש ולהיות מאובטח. למרבה המזל, יש תרופה בשם כותרת HSTS. עם זה אתה יכול להפעיל את כתובת האתר להפניה מחדש. הדפדפן יעבור לאתר מאובטח, אבל בזכות הכותרת HSTS גם לזכור את זה. כאשר המשתמש סוג ב whateversite.com יושב על הרשת לא מאובטח, הדפדפן ילך https מיד, מבלי לקפוץ דרך הפניה מחדש על פני http. אלא אם כן אתה מתמודד עם נתונים רגישים מאוד, אני חושב שזה סחר הוגן בין אבטחה ושימושיות עבור רוב האתרים. (כאשר אני לאחרונה להגדיר יישום טיפול רשומות רפואיות הלכתי כל https ללא הפניה). למרבה הצער, Internet Explorer אינו תומך ב- HSTS (מקור), כך שאם קהל היעד שלך משתמש בעיקר ב- IE והנתונים רגישים, ייתכן שתרצה להשבית הפניות מחדש.

אז אם אתה לא מתזמן משתמשי IE, קדימה ולהשתמש הפניה, אבל לאפשר את כותרת HSTS גם כן.


38
2018-01-28 07:40



יותר אנשים צריכים לשים לב לכך גם כן. דבר נוסף הוא שאנשים מניחים שהם בטוחים כי נקודת הסיום היא HTTPS, תוך התעלמות מהעובדה שכל המידע שנשלח לדף ב- GET או POST הוא בטקסט רגיל. - Velox
@ Velox - אני לא חושב שהמשמעות של "אנשים מניחים שהם בטוחים כי נקודת הסיום היא HTTPS, תוך התעלמות מהעובדה שכל המידע שנשלח לדף ב- GET או POST הוא בטקסט רגיל" הוא מדויק למדי. אמנם יש כמה gotchas, קבלת params שאילתה לא לנסוע ברור במהלך הובלה על HTTPS. ראה לדוגמה: stackoverflow.com/questions/323200/... מטעני POST מוגנים גם הם, אך גם אינם פגיעים לכותרות רישום ומפנה. - codingoutloud
@codingoutloud זו הנקודה שלי. במהלך HTTPS הם מוצפנים, אך בבקשת ההתחלה לדף HTTP הם לא. - Velox
@Velox - אם כל האתר מפנה מחדש ל- HTTPS, אזי אין זה סביר שכל פרמטרים של GET יישלחו לפני שה- HTTPS יכנס (והכל יישאר HTTPS לאחר הנקודה). יש עדיין את הבקשה הראשונית הראשונה שבה יישלחו קובצי Cookie, שניתן לתקן אותם עם HSTS ... וחלון התקפה קטן עבור SSLStrip, אשר יכול להיות מובס על ידי JavaScript, אבל זה מרוץ חימוש משלה. - Brilliand
@ נקודת בריליאנד הוגנת, אבל נקודת תורפה בביטחון עושה את כל העניין חלש. תמיד כדאי לשקול. - Velox


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

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

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

אם אתה רק מפרסם את האתר מעל TLS / SSL, אני ממליץ על הוראה נוספת כדי לאפשר HTTP אבטחה תחבורה קפדנית (HSTS) שלך לבטח מארח וירטואלי:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

כותרת זו מלמדת לקוחות מסוגלים (רובם בימים אלה, אני מאמין) שהם צריכים השתמש רק ב- HTTPS עם התחום הנתון (secure.example.com, במקרה זה) עבור הבא 1234 שניות. ה ; includeSubdomains חלק J אופציונאלי ומצביע על כך שההנחיה חלה לא רק על התחום הנוכחי, אלא על כל האמור בסעיף זה (למשל. alpha.secure.example.com). שים לב שכותרת ה- HSTS היא רק מקובל על ידי דפדפנים כאשר שימש מעל SSL / חיבור TLS!

כדי לבדוק את תצורת השרת שלך נגד בפועל הטוב ביותר הנוכחי, משאב חינם טוב הוא מבחן שרת SSL של Qualys שירות; אני הייתי שואף להבקיע לפחות A - (אתה לא יכול לקבל יותר מזה עם Apache 2.2 בשל היעדר תמיכה קריפטוגרפיה עקומה אליפטי).


22
2018-01-28 02:20



אני צריך להוסיף, לשלוח את הכותרת Strict-Transport-Security: max-age=0 תשלול כל הוראה קודמת; כמו תמיד, זה צריך להישלח על HTTPS כדי להתקבל, אבל זה דרך שימושית של ביטול דברים אם אתה מחליט שאתה גם צריך להשתמש ב- HTTP על התחום. - Calrion


וואו ! להפנות HTTP ל HTTPS הוא דבר טוב מאוד ואני לא יכול לראות כל החסרונות עבור זה.

רק לוודא הלקוחות שלך יש CA הנכון כדי למנוע אזהרות ידידותי למשתמש על אישור בדפדפן.

בנוסף, הדרך שבה הגדרת את Apache להפניה מחדש אל HTTPS נראית בסדר.


5
2018-01-28 00:35





האם זה רע להפנות http ל- https?

בכלל לא. למעשה, זה דבר טוב לעשות!

בהפניות מחדש:

זה יכול להיות יעיל יותר, על ידי לחלוטין ביטול rewrites. הנה התצורה שלי במצב דומה ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

5
2018-01-28 13:45





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

אבל זכור לזכור לבדוק את הגדרות SSL כמו הגדרת SSLCiphers. השבת דברים כמו הצפנת RC4, פרוטוקול SSLv2 ו- SSLv3. כמו כן, אתה צריך לגלות, אם librys מערכת הצפנה של תמיכה במערכת שלך TLS1.2 (וזה מה שאתה רוצה להיות))

הפעל SSL, זה דבר טוב.


4
2018-01-28 07:43



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


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


3
2018-01-28 10:13



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


הנה כמה מן הנושאים שבץ המכחול הרחב:

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

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

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


3
2018-04-19 10:43



הדבר שאתה יכול לעשות כדי לטפל בפועל sslstrip היא להשתמש HSTS (עדיף קבל את הגדרות HSTS שלך טעון מראש). בין אם אתה מקבל בקשות על HTTP רגיל או לא ממש לא משנה בעניין זה, MITM יכול לענות על HTTP רגיל (אולי proxying לאתר HTTPS שלך) גם אם אתה רק לקבל בקשות HTTPS. - Håkan Lindqvist
@ HåkanLindqvist אני באמת הרוויח ממך downvote? האם אני נותן עצה רעה או עצה טובה לגבי לא אימות מעל HTTPS ואז לעבור HTTP למשך שארית הפגישה? האם אני מספק ייעוץ גרוע לגבי מיתוסים של ביצועים HTTPS? כמו כן, אם הלקוח מנסה תחילה להתחבר באמצעות HTTPS, ה- MITM אינו יכול ליירט ולהגיב מבלי להפעיל התראה בדפדפן, מכיוון שה- cert שלהם לא יתאים אלא אם יש להם תעודת גניבה או זיוף בהצלחה. מצד שני, אם האתר מקבל חיבור HTTP, יירוט קל יותר. כך או כך, HTTPS מעלה את הסרגל. - Craig
.. וכמובן אני מסכים בלב שלם עם שימוש HSTS. - Craig
הבעיה שלי עם התשובה היא הפריט הראשון ברשימה הטוענת לכתובת sslstrip בזמן שהוא למעשה לא (מדבר על מיתוסים). מה אני מנסה להגיע ב ההערה הראשונית שלי היא שאם יש לך פעיל MITM (וזה מה שאתה צריך עבור sslstrip מלכתחילה), התוקף יכול בעצם להיות "האתר" מנקודת המבט של הלקוח; זה התוקף המחליט אם הם רוצים לקבל חיבורי HTTP פשוטים מהלקוח, איך שרת האינטרנט בפועל שלך מתנהג בהקשר זה אינו משפיע על מה שהתוקף יכול או יעשה. - Håkan Lindqvist
@ HåkanLindqvist אלא אם המבקר מנסה בכוונה להתחבר עם HTTPS, התוקף לא יכול לספק את הבקשה מבלי לזרוק דגלים בדפדפן, אלא אם כן הם הצליחו לגנוב תעודת שרת או איכשהו בהצלחה לזייף אחד, שבו הם היו צריכים לעשות כדי להעביר את החיבור ל- HTTP. HTTPS עדיין מעלה את הבר. כמובן, אם המבקר עושה את ניסיון ההתחברות הראשונית על HTTP, כל ההימורים הם לגמרי מחוץ. - Craig


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

אם נחזור לשאלה האמיתית שלך, אם אתה משתמש במשהו כמו HTTPSEverywhere, יש פחות תמריץ להשתמש ב- HTTP בלבד, למרות שאני מדמיין שקשה להגדיר כללים מתאימים כאשר אתה זקוק להם.


1
2018-01-28 04:27