Linux ਉੱਤੇ AnyConnect ਦਾ ਗੈਰ-ਵੈਧ TLS ਸੰਸਕਰਣ: ਪਹਿਲਾਂ ਸੁਧਾਰ ਦਾ ਦਾਇਰਾ ਤੈਅ ਕਰੋ

ਇਹ ਗਲਤੀ ਪਾਸਵਰਡ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਲਾਹੇਵੰਦ ਹਿੱਸਾ ਹੈ: ਹਾਲੇ ਕੁਝ ਵੀ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਹੋਇਆ, ਇਸ ਲਈ ਸਬੂਤ ਹੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹਨ। Linux ਉੱਤੇ ਉਹੀ AnyConnect ਸੰਵਾਦ ਪੁਰਾਣੇ ਪ੍ਰੋਟੋਕੋਲ ਸੰਸਕਰਣ, 1024-ਬਿੱਟ ਕੁੰਜੀ ਬਦਲਣ ਸਮੂਹ, ਜਾਂ ਅਜਿਹੇ ਸਾਈਫਰ ਸੈੱਟ ਤੋਂ ਆ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਸਿਸਟਮ ਦੀ ਕ੍ਰਿਪਟੋ ਨੀਤੀ ਰੱਦ ਕਰਦੀ ਹੈ। ਮੈਂ ਇਸਨੂੰ ਤਿੰਨ ਮਸ਼ੀਨਾਂ ਉੱਤੇ ਤਿੰਨ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਹਟਾਇਆ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਹੱਲਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਚਤੁਰਾਈ ਨਹੀਂ, ਪ੍ਰਭਾਵ ਦਾ ਦਾਇਰਾ ਹੈ। ਹਰ ਇੱਕ ਸਹੀ ਥਾਂ ਉੱਤੇ ਜਾਇਜ਼ ਹੈ ਅਤੇ ਬਾਕੀ ਹਰ ਥਾਂ ਖਰਾਬ ਡਿਫਾਲਟ।

ਨੀਤੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਨੇਹਾ ਪੜ੍ਹੋ

ਸੰਵਾਦ ਤੋਂ ਬਿਲਕੁਲ ਉਹੀ ਸਟਰਿੰਗ ਰੱਖੋ। ਸੰਸਕਰਣ ਦੀ ਸ਼ਿਕਾਇਤ ਪ੍ਰੋਟੋਕੋਲ ਪਰਤ ਵੱਲ, ਸਰਟੀਫਿਕੇਟ ਦੀ ਸ਼ਿਕਾਇਤ ਭਰੋਸੇ ਜਾਂ ਨਾਮਕਰਨ ਵੱਲ, ਅਤੇ ਅਸਫਲ ਲੌਗਇਨ ਸਬੂਤਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। TLS 1.0, 1024-ਬਿੱਟ DHE ਸਮੂਹ, AES-256-CBC ਅਤੇ SHA-1 ਦਸਤਖ਼ਤ ਦੇਣ ਵਾਲਾ ਗੇਟਵੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਰੱਖ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਤੁਹਾਡੇ ਸਬੂਤ ਭੇਜੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਆਧੁਨਿਕ ਨੀਤੀ ਵੱਲੋਂ ਰੱਦ ਹੋ ਸਕਦਾ ਹੈ।

ਸਿਸਟਮ ਦੇ OpenSSL ਨਾਲ ਐਂਡਪੌਇੰਟ ਜਾਂਚੋ, ਅਸਲ ਹੋਸਟਨਾਮ ਅਤੇ ਉਹ ਪੋਰਟ ਵਰਤਦਿਆਂ ਜੋ ਕਲਾਇੰਟ ਵਰਤਦਾ ਹੈ।

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ਅਸਫਲ ਹੋਵੇ ਅਤੇ -tls1 -cipher DEFAULT@SECLEVEL=0 ਸਫਲ ਹੋਵੇ ਤਾਂ ਸੀਮਾ ਸੰਸਕਰਣ ਅਤੇ ਕੁੰਜੀ ਦਾ ਆਕਾਰ ਦੋਵੇਂ ਹੈ। ਜੇ ਪਹਿਲਾ ਆਦੇਸ਼ ਪ੍ਰੋਟੋਕੋਲ ਚੇਤਾਵਨੀ ਦੀ ਥਾਂ ਛੋਟੀ DH ਕੁੰਜੀ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਸੰਸਕਰਣ ਠੀਕ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਸਮੂਹ ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਹੈ। ਜਾਂਚ ਵਿੱਚ ਕਦੇ ਵੀ ਨਿੱਜੀ ਕੁੰਜੀ ਜਾਂ ਪਾਸਵਰਡ ਨਾ ਪਾਓ।

ਵਿਕਲਪ 1: ਕ੍ਰਿਪਟੋ ਨੀਤੀ ਨਾਲ ਪੂਰਾ ਹੋਸਟ ਢਿੱਲਾ ਕਰੋ

Fedora ਅਤੇ RHEL 8 ਅਤੇ 9 ਉੱਤੇ, update-crypto-policies --set LEGACY OpenSSL ਦੀ ਸਿਸਟਮ ਨੀਤੀ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ update-crypto-policies --show ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਸਰਗਰਮ ਹੈ। ਇਹ ਆਮ ਤੌਰ ’ਤੇ ਟਨਲ ਬਹਾਲ ਕਰਦਾ ਹੈ, ਪਰ ਨੀਤੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਹੋਣ ਵੇਲੇ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਦੁਬਾਰਾ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਅਤੇ ਇਸ ਵੱਲੋਂ ਬਣਾਈ ਕੋਈ ਵੀ ਸਹਾਇਕ ਪ੍ਰਕਿਰਿਆ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ। ਇਹ ਮਸ਼ੀਨ ਉੱਤੇ ਹਰ TLS ਕਲਾਇੰਟ ਲਈ ਪੁਰਾਣੇ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਕਮਜ਼ੋਰ ਸਮੂਹਾਂ ਦੀ ਵੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਨਾਲ ਵਾਲੀ ਖਿੜਕੀ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਲੈ ਕੇ ਕਰਨਲ ਅੱਪਡੇਟ ਕਰਨ ਵਾਲੇ ਪੈਕੇਜ ਮੈਨੇਜਰ ਤੱਕ।

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

Debian ਅਤੇ Ubuntu ਕੋਲ ਇਸ ਲਈ ਇੱਕ ਵੀ ਸਵਿੱਚ ਨਹੀਂ ਹੈ। ਬਰਾਬਰ ਦਾ ਕੰਮ ਸਿਸਟਮ ਡਿਫਾਲਟ ਭਾਗ ਵਿੱਚ ਘੱਟ MinProtocol ਅਤੇ CipherString = DEFAULT@SECLEVEL=0 ਸੈੱਟ ਕਰਨ ਵਾਲੀ /etc/ssl/openssl.cnf ਸੋਧ ਹੈ। ਉਹੀ ਦਾਇਰਾ, ਵੱਖਰੀ ਫਾਈਲ, ਰਿਲੀਜ਼ ਅੱਪਗ੍ਰੇਡ ਵੇਲੇ ਨਜ਼ਰ ਤੋਂ ਗੁੰਮ ਹੋਣਾ ਥੋੜ੍ਹਾ ਸੌਖਾ।

ਵਿਕਲਪ 2: ਇੱਕ ਕਲਾਇੰਟ ਲਈ ਇੱਕ ਕਨਫਿਗ ਫਾਈਲ

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

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

OPENSSL_CONF ਨੂੰ ਉਸ ਫਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ ਅਤੇ VPN ਕਲਾਇੰਟ ਨੂੰ ਉਸ ਰੈਪਰ ਰਾਹੀਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਇਸਨੂੰ ਐਕਸਪੋਰਟ ਕਰਦਾ ਹੈ। ਹੋਸਟ ਉੱਤੇ ਬਾਕੀ ਸਭ ਡਿਫਾਲਟ ਨੀਤੀ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਅਨੁਕੂਲਤਾ ਦਾ ਸਵਾਲ ਆਉਣ ਵੇਲੇ ਇਹੀ ਗੁਣ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ। ਗੇਟਵੇ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਫਾਈਲ ਸੱਚਮੁੱਚ ਲਾਗੂ ਹੈ: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 ਨੂੰ TLS 1.0 ਸਾਈਫਰ ਸੂਚੀਬੱਧ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਖਾਲੀ ਨਤੀਜੇ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਲੜੀ ਟੁੱਟ ਗਈ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਨੇ ਚੁੱਪਚਾਪ ਸਿਸਟਮ ਡਿਫਾਲਟ ਰੱਖੇ ਹਨ।

ਫਾਈਲ ਸੰਸਕਰਣ ਪ੍ਰਤੀ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ। OpenSSL 1.1.1 ਅਤੇ 3.x ਉਹੀ ਭਾਗ-ਨਾਮ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ, ਪਰ ਪ੍ਰਦਾਤਾਵਾਂ ਦੁਆਲੇ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਸੰਭਾਲ 3.x ਵਿੱਚ ਬਦਲ ਗਈ, ਇਸ ਲਈ ਫਾਈਲ ਪੜ੍ਹੀ ਗਈ ਮੰਨਣ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਲੌਗ ਅਤੇ ਟੈਸਟ ਹੈਂਡਸ਼ੇਕ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ। ਭਾਗ ਦੇ ਨਾਮ ਵਿੱਚ ਟਾਈਪੋ ਖੁੱਲ੍ਹੇ ਤੌਰ ’ਤੇ ਅਸਫਲ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਚੁੱਪਚਾਪ ਸਿਸਟਮ ਡਿਫਾਲਟ ਵਰਤਦਾ ਹੈ।

ਸੀਮਾ ਕਵਰੇਜ ਹੈ। GnuTLS ਜਾਂ NSS ਨਾਲ ਲਿੰਕ ਕੀਤਾ ਕੁਝ ਵੀ OPENSSL_CONF ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਵਾਤਾਵਰਣ ਵਿਰਾਸਤ ਵਿੱਚ ਲਏ ਬਿਨਾਂ ਸ਼ੁਰੂ ਕੀਤੀ ਕੋਈ ਵੀ ਸਹਾਇਕ ਪ੍ਰਕਿਰਿਆ ਵੀ। ਰੈਪਰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ldd ਨਾਲ ਜਾਂਚੋ ਕਿ ਬਾਈਨਰੀ ਅਸਲ ਵਿੱਚ ਕਿਸ TLS ਲਾਇਬ੍ਰੇਰੀ ਨਾਲ ਲਿੰਕ ਹੈ, ਕਿਉਂਕਿ ਜਵਾਬ ਹੀ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਵਿਕਲਪ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ।

ਵਿਕਲਪ 3: ਇੱਕ ਵਾਰ ਵਰਤੋਂ ਵਾਲਾ VM ਜਾਂ ਕੰਟੇਨਰ

ਦੋ ਹਫ਼ਤਿਆਂ ਤੱਕ ਇੱਕ ਪੁਰਾਣੇ ਗੇਟਵੇ ’ਤੇ ਹਮਲਾ ਕਰਦੇ ਠੇਕੇਦਾਰ ਲਈ, ਢਿੱਲੀ ਨੀਤੀ ਵਾਲਾ ਸਮਰਪਿਤ VM ਵਰਕਸਟੇਸ਼ਨ ਤੋਂ ਸਾਫ਼ ਸੀਮਾ ਹੈ। ਪੁਰਾਣੀ ਸਤ੍ਹਾ ਅਤੇ ਰੋਜ਼ਾਨਾ ਬ੍ਰਾਊਜ਼ਰ ਪਰੋਫਾਈਲ ਹੁਣ ਕਰਨਲ ਨੀਤੀ ਸਾਂਝੀ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਨਿਪਟਾਰਾ ਆਡਿਟ ਖੋਜ ਨਹੀਂ, ਮਿਟਾਉਣਾ ਹੈ।

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

ਤੁਲਨਾ ਤੁਹਾਨੂੰ ਕੀ ਛੱਡਦੀ ਹੈ

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

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