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 ਪ੍ਰਾਕਸੀ ਭਰੋਸਾ ਸੈਟ ਕਰਦਾ ਹੈ ਅਤੇ ਮੰਜ਼ਿਲ ਦੀ ਤਸਦੀਕ ਵੱਖਰੀ ਰੱਖਦਾ ਹੈ; ਦੋਵੇਂ ਜਾਂਚਾਂ ਰੱਖੋ।

ਅਸਲ ਲਿਸਨਰ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਨਾਮ ਵੇਖੋ, ਫਿਰ ਕੰਟਰੋਲ ਹੇਠਲਾ ਉਹ ਸਰੋਤ ਵੀ ਜਾਂਚੋ ਜਿਸ ਨੂੰ ਰੱਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਸਿਰਫ਼ ਸਫਲ ਪਾਰਸਿੰਗ ਕਲਾਇੰਟ ਭਰੋਸਾ ਜਾਂ ਪਹੁੰਚ ਦੀ ਸੀਮਾ ਸਥਾਪਤ ਨਹੀਂ ਕਰਦੀ।

ਸੰਬੰਧਿਤ ਲੇਖ