Squid 6.13-ൽ TLS ഫോർവേഡ്-പ്രോക്സി ലിസണർ

GnuTLS അല്ലെങ്കിൽ OpenSSL ഉപയോഗിച്ച് നിർമിച്ച Squid 6.13-ന് 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 പ്രോക്സി ട്രസ്റ്റ് ക്രമീകരിച്ച് ലക്ഷ്യ പരിശോധന വേർതിരിക്കുന്നു; രണ്ടു പരിശോധനകളും നിലനിർത്തുക.

യഥാർഥ ലിസണറും സർട്ടിഫിക്കറ്റ് പേരും പരിശോധിച്ച്, നിരസിക്കേണ്ട നിയന്ത്രിത ഉറവിടവും പരീക്ഷിക്കുക. വിജയകരമായ പാഴ്സിങ് മാത്രം ക്ലയന്റ് വിശ്വാസമോ പ്രവേശനപരിധിയോ ഉറപ്പാക്കില്ല.