TLS ਗਲਤੀਆਂ ਸਿਰਫ਼ ਕਾਰਪੋਰੇਟ VPN ’ਤੇ: ਸਹੀ ਟਰੱਸਟ ਸਟੋਰ ਠੀਕ ਕਰੋ

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

ਤਿੰਨ ਸੁਨੇਹੇ, ਤਿੰਨ ਵਿਧੀਆਂ

x509 certificate signed by unknown authority ਗਲਤੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਚੇਨ ਬਣੀ ਅਤੇ ਉਸਦੀ ਜੜ੍ਹ ਉਸ ਟਰੱਸਟ ਸਟੋਰ ਵਿੱਚ ਨਹੀਂ ਹੈ ਜੋ ਉਹ ਪ੍ਰਕਿਰਿਆ ਵਰਤਦੀ ਹੈ। self-signed certificate in certificate chain ਗਲਤੀ ਦਾ ਆਮ ਮਤਲਬ ਹੈ ਕਿ ਜਾਂਚ ਪ੍ਰਾਕਸੀ ਨੇ ਆਪਣੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਨਾਲ ਜਵਾਬ ਦਿੱਤਾ, ਜੋ ਅਜਿਹੀ ਚੇਨ ਹੈ ਜਿਸਨੂੰ ਤੁਹਾਡਾ ਰਨਟਾਈਮ ਨਹੀਂ ਪਛਾਣਦਾ। ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ SSL EOF ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੋਈ ਵੀ ਵਰਤੋਂਯੋਗ ਪ੍ਰਮਾਣ ਪੱਤਰ ਭੇਜੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ ਬੰਦ ਹੋ ਗਿਆ, ਅਤੇ ਇਹ ClientHello ਨੂੰ ਰੱਦ ਕਰਨ ਵਾਲਾ ਵਿਚਕਾਰਲਾ ਯੰਤਰ ਹੈ, ਕੋਈ ਟਰੱਸਟ ਸਮੱਸਿਆ ਨਹੀਂ।

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

ਉਹ ਬੰਡਲ ਲੱਭੋ ਜੋ ਪ੍ਰਕਿਰਿਆ ਅਸਲ ਵਿੱਚ ਪੜ੍ਹਦੀ ਹੈ

Windows ਸਟੋਰ ਵਿੱਚ ਇੰਸਟਾਲ ਕਾਰਪੋਰੇਟ ਜੜ੍ਹ ਸਿਸਟਮ ਸਟੋਰ ਵੇਖਣ ਵਾਲੇ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ .NET ਐਪਲੀਕੇਸ਼ਨ ਠੀਕ ਕਰਦੀ ਹੈ। ਕੰਟੇਨਰ ਅੰਦਰ ਚੱਲਣ ਵਾਲੇ ਬਿਲਡ ਲਈ ਇਹ ਕੁਝ ਨਹੀਂ ਕਰਦੀ, ਕਿਉਂਕਿ ਉਸਦਾ ਆਪਣਾ CA ਬੰਡਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਨਾ ਹੀ certifi ਵਰਤਣ ਵਾਲੀ Python ਪ੍ਰਕਿਰਿਆ ਜਾਂ ਆਪਣੀ ਸ਼ਾਮਲ ਸੂਚੀ ਵਰਤਣ ਵਾਲੀ Node ਪ੍ਰਕਿਰਿਆ ਲਈ ਕੁਝ ਕਰਦੀ ਹੈ। Go ਉਸ ਵਾਤਾਵਰਣ ਦਾ ਸਿਸਟਮ ਪੂਲ ਪੜ੍ਹਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਬਾਈਨਰੀ ਚੱਲਦੀ ਹੈ, ਯਾਨੀ ਕੰਟੇਨਰ, ਲੈਪਟਾਪ ਨਹੀਂ। ਇਸ ਲਈ ਇੱਕੋ ਮਸ਼ੀਨ ਇੱਕੋ ਸਮੇਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਬਿਲਡ ਟੂਲ ਦਿੰਦੀ ਹੈ।

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਟੂਲ ਨੂੰ ਪੁੱਛੋ। python3 -c "import ssl; print(ssl.get_default_verify_paths())" ਉਹ ਫਾਈਲਾਂ ਛਾਪਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ Python ਸਲਾਹ ਲਵੇਗਾ, ਅਤੇ node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਓਵਰਰਾਈਡ ਪਹਿਲਾਂ ਹੀ ਸੈੱਟ ਹੈ ਜਾਂ ਨਹੀਂ। ਕੰਟੇਨਰ ਲਈ, ਉਹੀ ਜਾਂਚ ਇਮੇਜ ਅੰਦਰ ਚਲਾਓ, ਕਿਉਂਕਿ ਬਿਲਡ ਅਸਲ ਵਿੱਚ ਉਹੀ ਵਾਤਾਵਰਣ ਵਰਤਦਾ ਹੈ।

ਜਿੱਥੇ ਬਿਲਡ ਚੱਲਦਾ ਹੈ ਉੱਥੇ ਹੀ ਇੱਕ ਰੂਟ ਇੰਸਟਾਲ ਕਰੋ

ਜਾਂਚ ਜੜ੍ਹ IT ਤੋਂ PEM ਫਾਈਲ ਵਜੋਂ ਲਵੋ ਅਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੱਖਰੇ ਚੈਨਲ ਰਾਹੀਂ ਉਸਦੀ ਉਂਗਲ ਦੀ ਛਾਪ ਪਰਖੋ। Debian ਅਧਾਰਿਤ ਇਮੇਜਾਂ ਉੱਤੇ, ਇਸਨੂੰ /usr/local/share/ca-certificates/ ਵਿੱਚ ਕਾਪੀ ਕਰੋ ਅਤੇ update-ca-certificates ਚਲਾਓ; RHEL ਪਰਿਵਾਰ ਦੀਆਂ ਇਮੇਜਾਂ ਫਾਈਲ /etc/pki/ca-trust/source/anchors/ ਵਿੱਚ ਰੱਖਣ ਤੋਂ ਬਾਅਦ update-ca-trust ਵਰਤਦੀਆਂ ਹਨ। ਕੰਟੇਨਰ ਬਿਲਡ ਵਿੱਚ, ਅਸਫਲ ਹੋਣ ਵਾਲੇ ਕਮਾਂਡ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਕਦਮ ਜੋੜੋ ਤਾਂ ਜੋ ਪਰਤ ਨਿਰਭਰਤਾ ਇੰਸਟਾਲ ਤੋਂ ਉੱਪਰ ਕੈਸ਼ ਹੋਵੇ।

ਸਥਾਨਕ devcontainer ਲਈ, PEM ਮਾਊਂਟ ਕਰੋ ਅਤੇ ਸ਼ੁਰੂ ਵਿੱਚ ਉਹੀ ਅੱਪਡੇਟ ਕਮਾਂਡ ਚਲਾਓ, ਇਸਨੂੰ ਅਜਿਹੀ ਨਿੱਜੀ ਇਮੇਜ ਵਿੱਚ ਸੇਕਣ ਦੀ ਥਾਂ ਜਿਸਨੂੰ ਕੋਈ ਹੋਰ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾ ਸਕਦਾ। ਆਪਣਾ ਬੰਡਲ ਲਿਆਉਣ ਵਾਲੇ ਟੂਲਾਂ ਨੂੰ ਆਪਣਾ ਦਸਤਾਵੇਜ਼ੀ ਓਵਰਰਾਈਡ ਚਾਹੀਦਾ ਹੈ: pip ਵਿੱਚ ਪ੍ਰਮਾਣ ਪੱਤਰ ਸੈਟਿੰਗ ਹੈ, npm ਵਿੱਚ cafile ਸੈਟਿੰਗ ਹੈ, ਅਤੇ ਬਾਕੀ ਜ਼ਿਆਦਾਤਰ ਮਿਆਰੀ ਵਾਤਾਵਰਣ ਚਰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ।

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

ਜਦੋਂ ਹੈਂਡਸ਼ੇਕ ਪ੍ਰਮਾਣ ਪੱਤਰ ਤੋਂ ਪਹਿਲਾਂ ਮਰ ਜਾਂਦਾ ਹੈ

ਜੇ ਕੁਝ ਵੀ ਪੇਸ਼ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਤਾਂ ਟਰੱਸਟ ਸਟੋਰ ਦਾ ਕੋਈ ਵੀ ਬਦਲਾਅ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ। ਉਹੀ ਬੇਨਤੀ ਟਨਲ ਚਾਲੂ ਅਤੇ ਬੰਦ ਹਾਲਤ ਵਿੱਚ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ openssl s_client -connect host:443 -servername host -showcerts ਨਾਲ ਸਿੱਧੀ ਚੇਨ ਵੇਖੋ। ਜੋ ਕਨੈਕਸ਼ਨ VPN ਤੋਂ ਬਾਹਰ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਅੰਦਰ ਰੀਸੈਟ ਹੁੰਦਾ ਹੈ, ਉਹ ਵਿਚਕਾਰਲੇ ਯੰਤਰ ਦਾ ਨੀਤੀ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਉਪਾਅ ਉਸ ਹੋਸਟ ਲਈ ਛੋਟ ਹੈ, ਦੂਜਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਨਹੀਂ। ਪੈਕੇਜ ਰਜਿਸਟਰੀ ਜਾਂ API ਐਂਡਪਾਇੰਟ ਨੂੰ ਬਿਨਾਂ ਬਦਲਾਅ ਲੰਘਣ ਦੇਣ ਦੀ ਬੇਨਤੀ ਕਰੋ।

ਟਨਲ ਵੰਡ ਕੇ ਟੂਲ ਨੂੰ VPN ਤੋਂ ਬਚਾਉਣਾ ਉਸ ਟ੍ਰੈਫਿਕ ਲਈ ਜਾਂਚ ਟਾਲਦਾ ਹੈ, ਜੋ ਨੀਤੀ ਦੀ ਉਲੰਘਣਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਟੂਲ ਨੂੰ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦਾ।

ਹਰ ਟੂਲ ਲਈ ਨਤੀਜਾ ਲਿਖੋ

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

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