הפניה מחדש של בקשות HTTP נבחרות מ-Squid ל-HTTPS

Squid יכול לבקש מהדפדפן לנסות שוב כתובת HTTP נבחרת דרך HTTPS. היעד חייב כבר לספק את המשאב המתאים דרך HTTPS; הרצת Squid על Raspberry Pi אינה יוצרת יכולת זו באתר.

עבור ממשק url_rewrite_program של Squid 7, helper יכול להחזיר הפניית לקוח כזו:

OK status=307 url="https://www.example.com/help"

זוהי תגובת helper להמחשה לבקשה מתאימה, לא תוכנית helper שלמה. הדפדפן מקבל את ההפניה ושולח בקשה חדשה לכתובת ה-HTTPS. כתובת מחוץ למדיניות השדרוג יכולה לקבל OK ולהישאר ללא שינוי.

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

ה-helper חייב להשיב לכל שורת קלט לפי הפרוטוקול של גרסת Squid המותקנת. אם ערוצי helper מקבילים מופעלים, שמרו את מזהה הערוץ בתגובה. הדוגמה הישנה והחשופה 301:URL אינה ניתנת להחלפה בתבנית result-and-key/value הנוכחית.

בחרו בהפניית לקוח כאשר הדפדפן אמור לדעת את הכתובת החדשה. תגובת rewrite-url מבקשת מ-Squid להביא כתובת אחרת מאחורי הבקשה המקורית של הלקוח, מה שעלול להשאיר את כתובות האפליקציה ואת מצבה לא עקביים.

בקשת ה-HTTP הראשונית כבר הגיעה ל-Squid לפני שה-helper יכול להפנות אותה. המדיניות הזו אינה יכולה להגן על הבקשה בדיעבד. TLS מתחיל בחיבור ה-HTTPS הבא; מנהרת CONNECT בלבד אינה מספקת הצפנה.