شنوندهٔ پراکسی رو به جلو با TLS در Squid 6.13

Squid 6.13 اگر با GnuTLS یا OpenSSL ساخته شده باشد، می‌تواند درخواست‌های پراکسی رو به جلو را روی TLS بپذیرد. این کار پیوند کلاینت–پراکسی را محافظت می‌کند، بدون رهگیری نشست جداگانهٔ مقصد 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 اعتماد به پراکسی را تنظیم می‌کند و تأیید مقصد را جدا نگه می‌دارد؛ هر دو بررسی را حفظ کنید.

شنوندهٔ واقعی و نام گواهی را بررسی کنید، سپس مبدأ کنترل‌شده‌ای را هم بیازمایید که باید رد شود. موفقیت تجزیه به‌تنهایی اعتماد کلاینت یا مرز دسترسی را مشخص نمی‌کند.