ਜਾਂਚ ਪਰਾਕਸੀ ਦੇ ਕਿਹੜੇ ਪਾਸੇ ਨੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਰੱਦ ਕੀਤਾ?

ਕਲਾਇੰਟ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਜਾਂਚ ਪਰਾਕਸੀ 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ। ਫਿਰ ਵੀ ਬੇਨਤੀ ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ ਕਾਰਨ ਅਸਫਲ ਹੁੰਦੀ ਹੈ। ਦੋਵੇਂ ਤੱਥ ਸੱਚ ਹੋ ਸਕਦੇ ਹਨ: ਉਸ ਪਰਾਕਸੀ ਦਾ ਤਸਦੀਕ ਕਰਨ ਲਈ ਇੱਕ ਹੋਰ TLS ਸੰਬੰਧ ਹੈ।

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

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

ਤਸਦੀਕਕਰਤਾ ਦੀ ਗਲਤੀ ਪੜ੍ਹੋ

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

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

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

ਸਧਾਰਨ CONNECT ਸੁਰੰਗ ਵੱਖਰੀ ਹੈ

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

ਦੋਵੇਂ ਤਸਦੀਕ ਨਤੀਜੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦਰਜ ਕਰੋ। “ਪਰਾਕਸੀ ਦਾ ਸਰਟੀਫਿਕੇਟ ਭਰੋਸੇਯੋਗ ਹੈ” ਕਲਾਇੰਟ-ਪਾਸੇ ਦੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ; ਇਹ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਪਰਾਕਸੀ ਨੇ ਉੱਪਰ ਜੁੜਦਿਆਂ ਕੀ ਦੇਖਿਆ।