אפשרו יציאת HTTPS נוספת אחת דרך Squid
עדכנו את שתי רשימות ה־ACL של היציאות ב־Squid 6.13 והגבילו את היעד כששירות HTTPS מאושר משתמש ביציאה 8443.
שירות HTTPS ביציאה 8443 עלול להיכשל דרך שרת פרוקסי Squid שהוגדר כראוי, גם כאשר HTTPS רגיל ב־443 פועל. בדקו את דחיית CONNECT ואת מדיניות יציאות היעד לפני שינוי פרוטוקול הפרוקסי של הלקוח.
במדיניות גישה טיפוסית של Squid 6.13 חשובות שתי בדיקות: היעד חייב לעבור את Safe_ports, ו־CONNECT חייב לעבור את SSL_ports. הוספת היציאה לרשימת ACL אחת בלבד עלולה להשאיר את הדחייה האחרת בתוקף.
הרחיבו את ההגדרות הקיימות במכוון
למדיניות שמתירה יציאות רשת רגילות ויציאת HTTPS נוספת אחת:
acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443החליפו או ערכו את ההגדרות המתאימות כדי שלא תישאר קבוצת ערכים ישנה ולא צפויה. שמרו על הכללים הרגילים לדחיית יציאות לא בטוחות ו־CONNECT, וכן על הגבלות הלקוח המתוכננות.
שמרו על חריג מצומצם
אם היציאה הנוספת נחוצה רק ליעד מבוקר אחד, הוסיפו דחייה ממוקדת לפני הכלל שמתיר את הלקוח:
acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_targetהכתובת היא ערך לדוגמה לצורכי תיעוד. השתמשו ביעד שאתם מנהלים או מורשים לגשת אליו, והביאו בחשבון שינויים ממשיים בכתובתו. כך מצמצמים את החריג ליציאה הנוספת במקום להתיר כל יעד ב־8443.
בצעו ניתוח תחבירי של כל התצורה הפעילה ובדקו את סדר הכללים. דחייה שנכתבה נכון אך הוצבה אחרי כלל תואם שמתיר את הלקוח לא תספק את ההגבלה הרצויה.
בדקו את שם המארח המאושר עם התעודה והיציאה האמיתיות שלו, ולאחר מכן בדקו יעד מבוקר שאמור להישאר חסום. השאירו אימות TLS פעיל כדי להבחין בין שגיאות בזהות היעד לשגיאות במדיניות הפרוקסי. אל תסירו את כל הגנת CONNECT כדי לגרום לבקשה אחת ביציאה מותאמת לפעול.