ਲੰਮੀ SOCKS ਚੇਨ ਅਗਲੇ ਹੌਪ ਨੂੰ ਆਪਣੇ ਆਪ ਨਹੀਂ ਲੁਕਾਉਂਦੀ

ਚੇਨ ਬਦਲਦੀ ਹੈ ਕਿ ਹਰ ਕਨੈਕਸ਼ਨ ਕੌਣ ਖੋਲ੍ਹਦਾ ਹੈ। ਸੂਚੀ ਵਿੱਚ ਇੱਕ ਹੋਰ SOCKS ਪਤਾ ਜੋੜਨ ਨਾਲ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ ਜੁੜਦੀ।

ਇੱਕ ਕਲਾਇੰਟ ਬਾਰੇ ਸੋਚੋ ਜੋ ਇਹ ਚੇਨ ਖੁਦ ਬਣਾਉਂਦਾ ਹੈ:

application → SOCKS A → SOCKS B → website

ਇਹ ਪਹਿਲਾਂ A ਨੂੰ B ਨਾਲ ਜੁੜਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਉਸ ਸਟ੍ਰੀਮ ਰਾਹੀਂ ਇਹ ਫਿਰ B ਨਾਲ ਵੈੱਬਸਾਈਟ ਨਾਲ ਕਨੈਕਸ਼ਨ ਲਈ ਗੱਲਬਾਤ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਕਲਾਇੰਟ ਤੋਂ A ਤੱਕ ਆਵਾਜਾਈ ਦੋਵੇਂ ਗੱਲਬਾਤਾਂ ਨੂੰ ਬਿਨਾਂ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਲੈ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਉਸ ਲਿੰਕ ਉੱਤੇ ਕਾਫ਼ੀ ਸਮਰੱਥ ਨਿਰੀਖਕ ਕਲਾਇੰਟ ਵੱਲੋਂ ਭੇਜੇ ਸੈਟਅਪ ਬਾਈਟ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। ਬਾਹਰੀ TCP ਮੰਜ਼ਿਲ ਨਿਰੀਖਕ ਦਾ ਇੱਕੋ-ਇੱਕ ਸੰਭਾਵੀ ਸਬੂਤ ਨਹੀਂ ਹੈ।

ਚੇਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨ ਵਟਾਂਦਰੇ ਤੋਂ ਵੱਖ ਰੱਖੋ

HTTPS ਵੈੱਬਸਾਈਟ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਸਮੱਗਰੀ ਦੀ ਰੱਖਿਆ ਕਰ ਸਕਦਾ ਹੈ, ਉਸ ਦਾ TLS ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ। ਇਹ ਪਹਿਲਾਂ ਭੇਜੇ SOCKS ਸੈਟਅਪ ਸੁਨੇਹਿਆਂ ਨੂੰ ਪਿੱਛੇ ਜਾ ਕੇ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਦਾ। SOCKS5 ਦਾ ਵਰਤੋਂਕਾਰ-ਨਾਮ/ਪਾਸਵਰਡ ਪ੍ਰਮਾਣੀਕਰਨ ਵੀ ਐਨਕ੍ਰਿਪਟਿਡ ਆਵਾਜਾਈ ਨਹੀਂ ਹੈ।

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

ਸਰਵਰ ਉੱਤੇ ਸੰਰਚਿਤ ਪੇਰੈਂਟ ਰੂਟ ਇੱਕ ਹੋਰ ਟੋਪੋਲੋਜੀ ਹੈ। ਜੇ A ਅੰਦਰੋਂ B ਚੁਣਦਾ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਨੇ ਆਪਣੇ ਪਹਿਲੇ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਵਿਚੋਲਿਆਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਭੇਜੀ ਹੋਣੀ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਇਹ ਦਾਅਵਾ ਨਾ ਕਰੋ ਕਿ ਹਰ ਚੇਨ ਹਰ ਹੌਪ ਨੂੰ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਜ਼ਾਹਰ ਕਰਦੀ ਹੈ।

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