כיצד להפוך את HTTPS לבקשה הראשונה באמצעות VPN

דפדפן שמקליד תחילה http:// ונוחת על https:// לאחר שהפניה מחדש כבר שלח בקשה אחת בצורה ברורה, ו-VPN לא משנה זאת. המנהרה מגנה על הרגל מהלקוח לצומת היציאה; זה לא מצפין שום דבר מעל שכבת התחבורה, כך שמתבונן בין היציאה למקור עדיין רואה את הדילוג בטקסט הפשוט. הפיכת HTTPS לבקשה הראשונה היא שינוי בצד הלקוח הכולל שלושה חלקים: כתובת HTTPS אמיתית, מצב השדרוג של הדפדפן ומדיניות האתר עצמו. השלבים שלהלן הם ההזמנה שבה אני משתמש, כל אחד עם ההמחאה שאומר לך אם זה לקח.

שלב 1: אשר מהי בעצם הבקשה הראשונה

לפני שתשנה משהו, בדוק מה הדפדפן שולח. פתח את לוח הרשת כשהדף נטען מחדש ממטמון קר וקרא את השורה הראשונה: אם הסכימה היא http והסטטוס הוא 301 או 308, כל מה שאחרי השורה הזו הוא בקשה שנייה. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com משחזר את אותו רצף מחוץ לדפדפן ומדפיס את כתובת האתר שהגעת אליה.

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

שלב 2: הפעל את מצב HTTPS בלבד של הדפדפן

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

בפיירפוקס הפקדים חיים מאחורי about:config ובדף הגדרות הפרטיות, עם dom.security.https_only_mode כמתג וחריגים לכל אתר המנוהלים מתפריט המנעול. ב-Chrome וב-Edge אותו רעיון נמצא ב'הגדרות', 'פרטיות ואבטחה', 'אבטחה', עם התווית 'השתמש תמיד בחיבורים מאובטחים'. לא משנה מה התווית, ודא את ההתנהגות מול מארח שעונה רק ביציאה 80, מכיוון שמצב שמשדרג ואז נופל בשקט אינו ההגנה שאתה חושב שהפעלת. תיעוד Firefox HTTPS-Only מפרט את השדרוג, האזהרה והתנהגות החריגים של אותו דפדפן.

שלב 3: תקן את המשאבים, לא רק את שורת הכתובת

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

אל תוסיף חריג אישור לאתר חשבון מכיוון שה-VPN פועל. החריג משבית את הסימון שהיה תופס בדיוק את היירוט ש-VPN נועד למנוע.

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

שלב 4: מה HSTS מוסיף ומה לא

HSTS היא מדיניות אתר ולא העדפת דפדפן, וזהו המנגנון היחיד כאן ששורד http:// שהוקלד בפרופיל חדש. ברגע שדפדפן ראה כותרת Strict-Transport-Security עבור מארח, הוא משכתב בקשות מאוחרות יותר ל-https לפני שליחתן, שזה בדיוק הנכס שאתה רוצה. זה לא עושה כלום עבור מארח שהדפדפן מעולם לא ביקר בו, ושום דבר עבור שם מארח אחר שמשרת את אותו יישום.

בדוק מה המקור שולח עם curl -sSI https://example.com | grep -i strict-transport-security. כותרת חסרה היא שינוי שרת ולא משהו שלקוח יכול להתקין. אם הוא קיים, קרא את max-age והאם הוגדר includeSubDomains, מכיוון שגיל מקסימלי קצר פג בין ביקורים ו-includeSubDomains חסר משאיר כל תת-דומיין לא מוגן. RFC 6797 מגדיר כיצד סוכן משתמש מחיל את המדיניות וממה הוא עשוי להתעלם. טעינה מראש היא התחייבות נפרדת, אז בדוק את הסטטוס דרך ה-API של hstspreload.org לפני שאתה מבטיח למישהו שדומיין נמצא ברשימה.

אימות והחזרה לאחור

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

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

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