Squid 6.13 יכול לקבל בקשות פרוקסי קדמי על גבי TLS כשנבנה עם GnuTLS או OpenSSL. זה מגן על הקישור בין הלקוח לפרוקסי בלי ליירט את השיחה הנפרדת עם יעד ה-HTTPS.

  1. השיגו תעודה עבור שם המארח שהלקוחות ישתמשו בו כדי להגיע ל-Squid. הגבילו את המפתח הפרטי שלה לזהויות השירות שצריכות אותו.
  2. הוסיפו מאזין TLS עם הכתובת שהוקצתה לכם ונתיבי התעודות האמיתיים:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

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

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

curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/

השתמשו בשם המארח האמיתי של הפרוקסי ובקובץ ה-CA המאושר. תעודת פרוקסי בעלת אמון ציבורי עשויה לא לדרוש חבילה מותאמת. --proxy-cacert מגדיר אמון בפרוקסי ומשאיר אימות יעד נפרד; שמרו על שתי הבדיקות.

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

מאמרים קשורים