ਇੱਕ ਪੁਰਾਣਾ ਪੀਅਰ TLS 1.0 ਨੂੰ ਮਜਬੂਰ ਕਰਦਾ ਹੈ: ਛੋਟ ਨੂੰ ਸੀਮਤ ਕਰੋ, ਹੋਸਟ ਨੂੰ ਨਹੀਂ

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

ਨਿਰਦੇਸ਼ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲਤਾ ਨੂੰ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੋ

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

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

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

ਕਮਜ਼ੋਰ ਹੇਠਲੀ ਸੀਮਾ ਲਈ ਦੂਜਾ ਸੁਣਨ ਵਾਲਾ ਹੀ ਇਮਾਨਦਾਰ ਥਾਂ ਹੈ

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

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

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

ਪੁਰਾਣਾ ਪ੍ਰਦਾਤਾ ਸਰਟੀਫਿਕੇਟ ਅਸਲ ਵਿੱਚ ਕੀ ਤੋੜਦਾ ਹੈ

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

ਜਿਸਦਾ ਕੁੰਜੀ ਆਕਾਰ ਜਾਂ ਦਸਤਖ਼ਤ ਐਲਗੋਰਿਦਮ ਹੁਣ OpenSSL ਦੀ ਡਿਫ਼ਾਲਟ ਨੀਤੀ ਪੂਰੀ ਨਹੀਂ ਕਰਦਾ, ਅਜਿਹਾ ਪੁਰਾਣਾ ਪ੍ਰਦਾਤਾ ਸਰਟੀਫਿਕੇਟ ਕੰਟਰੋਲ ਚੈਨਲ 'ਤੇ ਸੀਮਤ ਸੁਰੱਖਿਆ ਪੱਧਰ ਬਦਲਣ ਦਾ ਮਾਮਲਾ ਹੈ। ਉੱਥੇ ਪੱਧਰ ਘਟਾਉਣ ਨਾਲ ਪੁਸ਼ਟੀ ਬੰਦ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਇਸਨੂੰ ਖਾਲੀ CA, ਬੰਦ ਪੁਸ਼ਟੀ ਜਾਂ ਬਿਨਾਂ ਜਾਂਚੇ ਹੋਸਟਨਾਮ ਨਾਲ ਕਦੇ ਨਹੀਂ ਜੋੜਨਾ ਚਾਹੀਦਾ। ਉਹ ਲਾਈਨ ਉਸੇ ਇੱਕ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਰੱਖੋ ਜਿਸਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ; ਢਿੱਲੀ ਕੀਤੀ OpenSSL ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਗਲੋਬਲ ਤੌਰ 'ਤੇ ਐਕਸਪੋਰਟ ਕਰਨ ਨਾਲ ਮਸ਼ੀਨ ਦੇ ਹਰ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਉਹੀ ਢਿੱਲ ਮਿਲੇਗੀ।

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

ਬੈਨਰ ਨਹੀਂ, ਗੱਲਬਾਤ ਵਿੱਚ ਤੈਅ ਹੋਏ ਮੁੱਲ ਪੜ੍ਹੋ

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

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

ਹਰ ਛੋਟ ਨੂੰ ਮਾਲਕ ਅਤੇ ਤਾਰੀਖ਼ ਚਾਹੀਦੀ ਹੈ

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

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