ਗਲਤੀ ਕਹਿੰਦੀ ਹੈ “ਗਲਤ ਸੰਸਕਰਣ”, ਇਸ ਲਈ TLS ਸੰਸਕਰਣ ਬਦਲਣਾ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਲਾਲਚ ਹੁੰਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਨਾਲ, ਪਹਿਲਾਂ ਦੀ ਇੱਕ ਸੰਭਾਵਨਾ ਵੇਖੋ: ਕੀ ਕਲਾਇੰਟ ਨੇ ਸਾਦੇ HTTP ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਪੋਰਟ ਉੱਤੇ TLS ਹੈਂਡਸ਼ੇਕ ਭੇਜਿਆ ਸੀ?

https://example.com/ ਵਰਗਾ ਟਿਕਾਣਾ ਅਤੇ http://proxy.example:8080 ਵਰਗਾ ਪ੍ਰੌਕਸੀ ਆਮ ਜੋੜੀ ਹਨ। ਦੂਜੀ URL ਨੂੰ HTTPS ਬਣਾਉਣਾ ਕਲਾਇੰਟ ਨੂੰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਹ ਆਪਣੀ ਗੱਲਬਾਤ ਪ੍ਰੌਕਸੀ ਨਾਲ ਹੀ ਐਨਕ੍ਰਿਪਟ ਕਰੇ। ਇਹ HTTPS ਸਾਈਟਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਦਾ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਹੈ।

ਪਹਿਲੀ TLS ਗੱਲਬਾਤ ਲੱਭੋ

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

HTTP ਗਲਤੀ ਪੰਨਾ ਜਾਂ ਹੋਰ ਸਾਦਾ ਟੈਕਸਟ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ TLS ਪਾਰਸਰ ਪ੍ਰੋਟੋਕੋਲ ਗਲਤੀ ਦੀ ਰਿਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ। ਉਹ ਸ਼ਬਦ ਇਹ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦੇ ਕਿ ਸਾਈਟ ਕਿਹੜੇ TLS ਸੰਸਕਰਣ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਜਾਂ ਸਾਈਟ ਨਾਲ ਸੰਪਰਕ ਹੋਇਆ ਵੀ ਸੀ ਜਾਂ ਨਹੀਂ।

  1. ਪ੍ਰੌਕਸੀ ਦੀ URL, ਉਸ ਦੇ ਸਕੀਮ ਸਮੇਤ, ਅਤੇ ਐਂਡਪੌਇੰਟ ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਪ੍ਰੋਟੋਕੋਲ ਦਰਜ ਕਰੋ।
  2. ਪਤਾ ਲਗਾਓ ਕਿ ਨਾਕਾਮੀ CONNECT ਜਵਾਬ ਤੋਂ ਪਹਿਲਾਂ, ਟਿਕਾਣੇ ਦੇ TLS ਦੌਰਾਨ, ਜਾਂ ਪ੍ਰੌਕਸੀ ਦੇ ਆਪਣੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਪੜਤਾਲ ਦੌਰਾਨ ਹੋਈ ਸੀ।
  3. ਪੁਰਾਣੇ ਹੱਲ ਦੀ ਤੁਲਨਾ ਕਰਦਿਆਂ ਅਸਲ ਕਲਾਇੰਟ ਅਤੇ ਨਿਰਭਰਤਾਵਾਂ ਦੇ ਸੰਸਕਰਣ ਜਾਂਚੋ। ਪਹਿਲੇ ਪ੍ਰੌਕਸੀ ਲਾਗੂਕਰਨ ਕਈ ਵਾਰ ਸਕੀਮ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਲੈਂਦੇ ਸਨ।

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

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

ਸੰਬੰਧਿਤ ਲੇਖ