HTTPS ਪ੍ਰੌਕਸੀ ਲੇਬਲ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਕਲਾਇਟ ਅਤੇ ਪ੍ਰੌਕਸੀ ਵਿਚਕਾਰ ਆਵਾਜਾਈ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ। ਇਹ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਇਸ ਪਿੱਛੇ ਦੀ ਵੈੱਬਸਾਈਟ ਉਸੇ ਕਨੈਕਸ਼ਨ ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਪ੍ਰੌਕਸੀ ਪੇਜ ਪੜ੍ਹ ਸਕਦੀ ਹੈ। ਦੋਵੇਂ ਕਨੈਕਸ਼ਨ ਵੱਖ ਕਰਨ ਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀਆਂ ਗਲਤੀਆਂ ਰਹੱਸਮਈ ਰਹਿਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ VPN ਨਾਲ ਤੁਲਨਾ ਟਿਕਾਊ ਹੋ ਜਾਂਦੀ ਹੈ।

ਦੋ ਸਿਰਿਆਂ ਦੇ ਜੋੜੇ, ਦੋ ਪ੍ਰਮਾਣਿਕਤਾਵਾਂ

ਆਮ ਟਨਲ ਮੋਡ ਵਿੱਚ ਦੋ TLS ਸੰਬੰਧ ਹੁੰਦੇ ਹਨ। ਪਹਿਲਾ ਤੁਹਾਡੇ ਕਲਾਇਟ ਤੋਂ ਪ੍ਰੌਕਸੀ ਤੱਕ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰੌਕਸੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ। ਦੂਜਾ ਤੁਹਾਡੇ ਕਲਾਇਟ ਤੋਂ ਟਨਲ ਦੇ ਅੰਦਰ ਵੈੱਬਸਾਈਟ ਤੱਕ ਜਾਂਦਾ ਹੈ ਅਤੇ ਵੈੱਬਸਾਈਟ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ। ਉਹ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਸੰਰਚਿਤ ਹੁੰਦੇ ਹਨ।

ਉਹਨਾਂ ਦੇ ਵੱਖਰੇ ਭਰੋਸਾ ਫੈਸਲੇ, ਵੱਖਰੀਆਂ ਸਰਟੀਫਿਕੇਟ ਚੇਨਾਂ ਅਤੇ ਵੱਖਰੇ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਸੁਨੇਹੇ ਹਨ। ਸੰਸਥਾਗਤ CA ਵਰਤਣ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਅਤੇ ਜਨਤਕ ਚੇਨ ਵਰਤਣ ਵਾਲੀ ਜਨਤਕ ਵੈੱਬਸਾਈਟ ਨੂੰ ਵੈਧ ਰੂਪ ਵਿੱਚ ਵੱਖਰੀ ਪ੍ਰਮਾਣਿਕਤਾ ਸੰਰਚਨਾ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਇਹ ਗਲਤ ਸੰਰਚਨਾ ਨਹੀਂ ਹੈ।

ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਸਾਕਟ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਦੋ ਕਨੈਕਸ਼ਨਾਂ ਵਜੋਂ ਵੇਖੋ, ਕਿਉਂਕਿ ਉਹ ਅਜਿਹੇ ਹੀ ਹਨ।

CONNECT ਅਸਲ ਵਿੱਚ ਕੀ ਟਨਲ ਕਰਦਾ ਹੈ

ਕਲਾਇਟ ਹੋਸਟ ਅਤੇ ਪੋਰਟ ਦਾ ਨਾਮ ਦੇ ਕੇ CONNECT ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੌਕਸੀ ਉਸ ਟਾਰਗੇਟ ਨਾਲ TCP ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦੀ ਹੈ। ਪ੍ਰੌਕਸੀ ਦੇ ਜਵਾਬ ਦੇਣ ਤੋਂ ਬਾਅਦ, ਅੱਗੇ ਆਉਣ ਵਾਲੇ ਬਾਈਟ ਬਿਨਾਂ ਵਿਆਖਿਆ ਦੇ ਰੀਲੇ ਹੁੰਦੇ ਹਨ, ਇਸੇ ਲਈ ਵੈੱਬਸਾਈਟ ਦਾ TLS ਹੈਂਡਸ਼ੇਕ ਪ੍ਰੌਕਸੀ ਵਿੱਚੋਂ ਅਛੂਤਾ ਲੰਘਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਪ੍ਰੌਕਸੀ ਮੰਜ਼ਿਲ ਦਾ ਨਾਮ ਅਤੇ ਕਨੈਕਸ਼ਨ ਦਾ ਮੈਟਾਡੇਟਾ ਜਾਣ ਲੈਂਦੀ ਹੈ, ਪਰ ਉਸ ਵਿਵਸਥਾ ਤੋਂ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਪੇਜ ਨਹੀਂ ਪ੍ਰਾਪਤ ਕਰਦੀ।

ਇਹ ਫ਼ਰਕ ਟਨਲ ਮੋਡ ਦੀ ਪੂਰੀ ਸੁਰੱਖਿਆ ਦਲੀਲ ਹੈ, ਅਤੇ ਇਹੀ ਇਸਦੀ ਹੱਦ ਹੈ।

ਪ੍ਰੌਕਸੀ ਹੌਪ ਤੇ TLS ਤੋਂ ਬਿਨਾਂ HTTP ਪ੍ਰੌਕਸੀ ਫਿਰ ਵੀ CONNECT ਰਾਹੀਂ HTTPS ਵੈੱਬਸਾਈਟ ਢੋਂਦੀ ਹੈ। ਕਲਾਇਟ-ਤੋਂ-ਪ੍ਰੌਕਸੀ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਖੁੱਲ੍ਹਾ ਹੁੰਦਾ ਹੈ ਜਦਕਿ ਵੈੱਬਸਾਈਟ ਕਨੈਕਸ਼ਨ ਨਹੀਂ, ਅਤੇ ਪੂਰੀ ਗੱਲ ਨੂੰ HTTPS ਪ੍ਰੌਕਸੀ ਕਹਿਣਾ ਉਹ ਫ਼ਰਕ ਲੁਕਾਉਂਦਾ ਹੈ।

ਕਿਹੜਾ ਸਰਟੀਫਿਕੇਟ ਫੇਲ੍ਹ ਹੋਇਆ

ਜਦੋਂ ਪ੍ਰਮਾਣਿਕਤਾ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਕੋਈ ਵੀ ਭਰੋਸਾ ਸੈਟਿੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਗਲਤੀ ਵਿੱਚ ਦੱਸੇ ਸਿਰੇ ਨੂੰ ਪੜ੍ਹੋ। ਦੋਵੇਂ ਫੇਲ੍ਹ ਟਰਮੀਨਲ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ ਅਤੇ ਬਿਲਕੁਲ ਵੱਖਰੇ ਸੁਧਾਰਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਪਹਿਲਾ ਸਵਾਲ ਹਮੇਸ਼ਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਕਨੈਕਸ਼ਨ ਇਨਕਾਰ ਕੀਤਾ।

curl ਠੀਕ ਇਸੇ ਕਾਰਨ ਵਿਕਲਪ ਵੱਖ ਰੱਖਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਦੀ CA ਫਾਈਲ ਪ੍ਰੌਕਸੀ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਸੰਰਚਿਤ ਕਰਦੀ ਹੈ, ਜਦਕਿ CA ਫਾਈਲ ਸਰਵਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਸੰਰਚਿਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲੇ ਟਰੱਸਟ ਸਟੋਰ ਦਾ ਵਿਵਹਾਰ ਵੀ curl ਕਿਵੇਂ ਬਣਾਇਆ ਗਿਆ ਇਸ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

ਜਾਂਚ ਦਬਾਉਣਾ ਮੁਰੰਮਤ ਨਹੀਂ ਹੈ। ਇਹ ਦੋਵੇਂ ਸਿਰਿਆਂ ਵਿੱਚੋਂ ਕਿਸੇ ਬਾਰੇ ਵੀ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।

ਨਿਰੀਖਣ ਇੱਕ ਵੱਖਰੀ ਵਿਵਸਥਾ ਹੈ

TLS ਨਿਰੀਖਣ ਟਨਲਿੰਗ ਨਹੀਂ ਹੈ। ਨਿਰੀਖਣ ਕਰਨ ਵਾਲਾ ਵਿਚੋਲਾ ਵੈੱਬਸਾਈਟ ਵੱਲ ਦਾ ਭਰੋਸਾ ਸੰਬੰਧ ਖ਼ਤਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲਾਇਟ ਨੂੰ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਕਲਾਇਟ ਸਾਈਟ ਦੀ ਥਾਂ ਵਿਚੋਲੇ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ। ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਡਿਜ਼ਾਈਨ ਹੇਠ ਇਹ ਵੈਧ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਬਾਈਟ-ਦਰ-ਬਾਈਟ ਰੀਲੇ ਤੋਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਵੱਖਰਾ ਦਾਅਵਾ ਹੈ। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਹਰ ਪ੍ਰੌਕਸੀ ਨਿਰੀਖਣ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਨਾ ਮੰਨੋ ਕਿ ਐਨਕ੍ਰਿਪਟਿਡ ਪ੍ਰੌਕਸੀ ਹੌਪ ਇਸ ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਤੁਹਾਡੇ ਟਰੱਸਟ ਸਟੋਰ ਵਿੱਚ ਸੰਸਥਾਗਤ CA ਇਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਵਿਵਸਥਾ ਵਿੱਚ ਹੋ, ਸਬੂਤ ਨਹੀਂ। ਸਰਟੀਫਿਕੇਟ ਚੇਨ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਡਿਜ਼ਾਈਨ ਪੁੱਛੋ।

ਉਹ ਦੋਵੇਂ ਵਿਵਸਥਾਵਾਂ ਇਸ ਸਵਾਲ ਦੇ ਵੱਖਰੇ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਪੇਜ ਕੌਣ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।

ਉਹਨਾਂ ਹੀ ਚਾਰ ਲਾਈਨਾਂ ਤੇ ਪ੍ਰੌਕਸੀ ਅਤੇ VPN ਦੀ ਤੁਲਨਾ ਕਰੋ

ਦੋਵੇਂ ਤੈਨਾਤੀਆਂ ਨੂੰ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਕਰਨ ਤੇ ਹੀ ਤੁਲਨਾ ਲਾਹੇਵੰਦ ਹੁੰਦੀ ਹੈ।

LineWhat to state
Protected segmentsWhich hops are encrypted, and between which endpoints
Verified identitiesWhat each end proves, and against which trust anchor
Trusted intermediariesWho can read or alter traffic by design
Traffic includedWhich processes and destinations the policy actually covers

ਇੱਕ ਬੇਨਤੀ ਲਈ ਸੰਰਚਿਤ ਪ੍ਰੌਕਸੀ ਉਸ ਬੇਨਤੀ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ। ਇਹ ਡਿਵਾਈਸ ਦੀ ਹਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਪਣੇ ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਾਉਂਦੀ, ਅਤੇ ਉਦਾਹਰਨ ਕਮਾਂਡ ਠੀਕ ਉੱਨੀ ਹੀ ਤੰਗ ਹੈ। VPN ਦੀ ਕਵਰੇਜ ਇਸਦੀ ਰੂਟਿੰਗ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੀਤੀ ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਜਿਹਨਾਂ ਨੂੰ ਵੀ ਮੰਨਣ ਦੀ ਥਾਂ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੋਈ ਵੀ ਵਿਕਲਪ ਸਿਰਫ਼ ਇੰਸਟਾਲ ਹੋਣ ਕਾਰਨ ਸਭ ਕੁਝ ਕਵਰ ਨਹੀਂ ਕਰਦਾ।

ਹਰ ਵਿਕਲਪ ਲਈ ਚਾਰ ਲਾਈਨਾਂ ਲਿਖੋ ਅਤੇ ਬਹਿਸ ਆਮ ਤੌਰ ਤੇ ਆਪਣੇ ਆਪ ਹੱਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਲਾਹੇਵੰਦ ਤੁਲਨਾ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਲੇਬਲ ਵਧੇਰੇ ਐਨਕ੍ਰਿਪਟਿਡ ਸੁਣਦਾ ਹੈ। ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਕਿਹੜੇ ਹਿੱਸੇ ਸੁਰੱਖਿਅਤ ਹਨ, ਉਹਨਾਂ ਦੇ ਸਿਰਿਆਂ ਤੇ ਕਿਸ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਹੁੰਦੀ ਹੈ, ਕਿਹੜੇ ਵਿਚੋਲਿਆਂ ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ, ਅਤੇ ਨੀਤੀ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਟ੍ਰੈਫਿਕ ਸਮੇਟਦੀ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ