ਕੀ OpenVPN ਵਿੱਚ dh none ਨਾਲ RSA ਸਰਟੀਫਿਕੇਟ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ?
ਸਰਟੀਫਿਕੇਟ ਦੀ ਕਿਸਮ ਅਤੇ ਕੁੰਜੀ-ਬਦਲ ਬਦਲੀ ਸਮੂਹ TLS ਦੀਆਂ ਦੋ ਵੱਖਰੀਆਂ ਚੋਣਾਂ ਹਨ। RSA ਸਰਟੀਫਿਕੇਟ ECDHE ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ dh none ਨੂੰ EC ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਲੋੜ ਨਹੀਂ।
ਇੱਥੇ RSA ਕਹਿਣ ਵਾਲੇ ਸਰਟੀਫਿਕੇਟ ਦੇ ਨਾਲ dh none ਕਹਿਣ ਵਾਲਾ ਸਰਵਰ ਸੰਰਚਨਾ ਹੈ, ਨਾਲ ਹੀ ਇਹ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲਾ ਸ਼ੱਕ ਕਿ ਦੋਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜ਼ਰੂਰ ਗਲਤ ਹੋਵੇਗਾ। ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਦਸਤਖਤ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ; ਕੁੰਜੀ-ਬਦਲ ਬਦਲੀ ਸਾਂਝਾ ਭੇਤ ਸਥਾਪਿਤ ਕਰਦੀ ਹੈ। ਇਹ ਇੱਕੋ ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਦੋ ਵੱਖਰੇ ਕੰਮ ਹਨ, ਅਤੇ TLS RSA ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਅਜਿਹਾ ਹੈਂਡਸ਼ੇਕ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜੋ ਅਸਥਾਈ ਅੰਡਾਕਾਰ-ਵਕਰ ਸਮਝੌਤਾ ਵਰਤਦਾ ਹੈ।
ਉਲਝਣ ਆਮ ਤੌਰ 'ਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਗਾਈਡ ਨਾਲ ਆਉਂਦੀ ਹੈ। ਇਹ DH ਪੈਰਾਮੀਟਰ ਫਾਈਲ ਨੂੰ dh none ਨਾਲ ਬਦਲਣ ਲਈ ਕਹਿੰਦੀ ਹੈ, ਪਾਠਕ ਦੇਖਦਾ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਅੰਡਾਕਾਰ-ਵਕਰ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਤੱਥ ਵਿਰੋਧਾਭਾਸ ਵਜੋਂ ਲਏ ਜਾਂਦੇ ਹਨ।
ਦੋ ਸੈਟਿੰਗਾਂ ਸੰਬੰਧਿਤ ਕਿਉਂ ਲੱਗਦੀਆਂ ਹਨ
OpenVPN ਦੀ ਪੁਰਾਣੀ ਸੰਰਚਨਾ DH ਪੈਰਾਮੀਟਰ ਫਾਈਲ ਮੰਗਦੀ ਸੀ ਕਿਉਂਕਿ ਸੀਮਤ-ਖੇਤਰ Diffie-Hellman ਨੂੰ ਉਹ ਡੋਮੇਨ ਪੈਰਾਮੀਟਰ ਚਾਹੀਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਦੋਵੇਂ ਧਿਰਾਂ ਸਹਿਮਤ ਹੋਣ। dh ਹਦਾਇਤ ਉਸ ਫਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਸੀ। ਜਦੋਂ ਤੈਨਾਤੀ ECDH 'ਤੇ ਜਾਂਦੀ ਹੈ, ਪੈਰਾਮੀਟਰ ਇਸ ਦੀ ਬਜਾਏ ਨਾਮਿਤ ਵਕਰ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਅਤੇ ਫਾਈਲ ਦੀ ਹੁਣ ਲੋੜ ਨਹੀਂ, ਜੋ dh none ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ।
ਸਰਟੀਫਿਕੇਟ ਵੱਖਰੀ ਧੁਰੀ ਹਨ। ਉਹ ਸਰਵਰ ਦੀ ਪਛਾਣ ਸਾਬਤ ਕਰਨ ਵਾਲੀ ਜਨਤਕ ਕੁੰਜੀ ਅਤੇ ਦਸਤਖਤ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਉਹ ਕੁੰਜੀ ਸੈਸ਼ਨ ਕੁੰਜੀ ਕਿਵੇਂ ਸਹਿਮਤ ਹੁੰਦੀ ਹੈ ਇਸ ਤੋਂ ਬਿਨਾਂ RSA ਜਾਂ ਅੰਡਾਕਾਰ ਵਕਰ ਹੋ ਸਕਦੀ ਹੈ। ਕੁੰਜੀ ਸਮਝੌਤੇ ਲਈ ECDHE ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ RSA ਵਰਤਣ ਵਾਲਾ ਹੈਂਡਸ਼ੇਕ ਆਮ ਹੈ ਅਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਤੈਨਾਤ ਹੈ।
ਨਾਮਕਰਨ ਓਵਰਲੈਪ ਨੂੰ ਹੋਰ ਮਾੜਾ ਕਰਦਾ ਹੈ। ਅੰਡਾਕਾਰ ਵਕਰ ECDHE ਅਤੇ ECDSA ਦੋਵੇਂ ਸੂਟ ਨਾਵਾਂ ਵਿੱਚ ਦਿਖਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਮੰਨਣਾ ਸੌਖਾ ਹੈ ਕਿ ਵਕਰ ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਵਕਰ ਸਰਟੀਫਿਕੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹਾ ਨਹੀਂ ਹੈ।
TLS 1.2 ਸੂਟ ਨਾਮ ਸਹੀ ਢੰਗ ਨਾਲ ਪੜ੍ਹਨਾ
ECDHE-RSA-AES256-GCM-SHA384 ਲਓ। ਪਹਿਲਾ ਟੋਕਨ ਕੁੰਜੀ-ਬਦਲ ਬਦਲੀ ਪਰਿਵਾਰ ਹੈ: ਅਸਥਾਈ ਅੰਡਾਕਾਰ-ਵਕਰ Diffie-Hellman। ਦੂਜਾ ਪ੍ਰਮਾਣੀਕਰਨ ਪਰਿਵਾਰ ਹੈ: RSA। ਬਾਕੀ ਰਿਕਾਰਡ ਸੁਰੱਖਿਆ ਅਤੇ ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਵਰਤੇ ਹੈਸ਼ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।
ECDHE-ECDSA ਸੂਟ ਉਹੀ ਕੁੰਜੀ-ਬਦਲ ਬਦਲੀ ਪਰਿਵਾਰ ਵੱਖਰੀ ਪ੍ਰਮਾਣੀਕਰਨ ਵਿਧੀ ਨਾਲ ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਅੰਡਾਕਾਰ-ਵਕਰ ਸਰਟੀਫਿਕੇਟ ਚਾਹੀਦਾ ਹੈ। DHE-RSA ਸੂਟ RSA ਪ੍ਰਮਾਣੀਕਰਨ ਨਾਲ ਸੀਮਤ-ਖੇਤਰ ਅਸਥਾਈ Diffie-Hellman ਵਰਤਦਾ ਹੈ, ਅਤੇ ਉਸਨੂੰ ਸੱਚਮੁੱਚ DH ਪੈਰਾਮੀਟਰ ਚਾਹੀਦੇ ਹਨ।
ਸੂਟ ਨਾਮ ਖੱਬੇ ਤੋਂ ਸੱਜੇ ਪੜ੍ਹੋ ਅਤੇ ਹਰ ਹਿੱਸੇ ਨੂੰ ਉਸਦੇ ਕੰਮ ਸੌਂਪੋ। ਟੋਕਨ ਵੱਖ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਸਵਾਲ «ਕੀ ਮੇਰਾ ਸਰਟੀਫਿਕੇਟ dh none ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ» ਤੋਂ «ਕੀ ਮੇਰਾ ਸਰਵਰ ਅਜਿਹੀ ਸੂਟ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ ਕੁੰਜੀ-ਬਦਲ ਬਦਲੀ ਨੂੰ DH ਫਾਈਲ ਦੀ ਲੋੜ ਨਹੀਂ» ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
dh none ਅਸਲ ਵਿੱਚ ਕੀ ਅਸਮਰੱਥ ਕਰਦਾ ਹੈ
dh none ਸਰਵਰ ਨੂੰ ਸੀਮਤ-ਖੇਤਰ DH ਪੈਰਾਮੀਟਰ ਫਾਈਲ ਲੋਡ ਨਾ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਇਹ ਪ੍ਰਮਾਣੀਕਰਨ, ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ TLS ਆਪਣੇ ਆਪ ਨੂੰ ਅਸਮਰੱਥ ਨਹੀਂ ਕਰਦਾ। ਪਰ ਇਹ ਮੰਗ ਕਰਦਾ ਹੈ ਕਿ ਸਹਿਮਤ ਕੁੰਜੀ-ਬਦਲ ਬਦਲੀ ਉਹ ਹੋਵੇ ਜਿਸਨੂੰ ਉਹ ਪੈਰਾਮੀਟਰ ਲੋੜੀਂਦੇ ਨਾ ਹੋਣ, ਜਿਸਦਾ ਵਿਵਹਾਰ ਵਿੱਚ ਅਰਥ ECDHE ਸੂਟ ਜਾਂ TLS 1.3 ਹੈਂਡਸ਼ੇਕ ਹੈ।
ਇਸੇ ਮੰਗ ਤੋਂ ਟੁੱਟਣ ਆਉਂਦੀ ਹੈ। ਜੇ ਸਰਵਰ ਦੀ TLS ਸਾਈਫਰ ਨੀਤੀ DHE ਸੂਟ ਤੱਕ ਸੀਮਿਤ ਹੈ, ਜਾਂ ਕਲਾਇੰਟ ਸਿਰਫ਼ ਉਹੀ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਪੈਰਾਮੀਟਰ ਫਾਈਲ ਹਟਾਉਣ ਨਾਲ ਕੋਈ ਵਰਤੋਂਯੋਗ ਕੁੰਜੀ-ਬਦਲ ਬਦਲੀ ਢੰਗ ਨਹੀਂ ਬਚਦਾ ਅਤੇ ਹੈਂਡਸ਼ੇਕ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ। ਗਲਤੀ ਆਮ ਤੌਰ 'ਤੇ ਕੰਟਰੋਲ-ਚੈਨਲ ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ, ਕਿਸੇ ਵੀ ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣੀਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਦੀ ਹੈ। ਗੁੰਮ ਫਾਈਲ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਈਫਰ ਸੂਚੀ ਪੜ੍ਹੋ।
ਅੰਡਾਕਾਰ-ਵਕਰ ਵਾਲੇ ਪਾਸੇ, ਵਕਰ ਸਰਵਰ ਦੀ TLS ਸੰਰਚਨਾ ਚੁਣਦੀ ਹੈ, ਅਤੇ OpenVPN ਪੁਰਾਣੀਆਂ ਸ਼ਾਖਾਵਾਂ 'ਤੇ ਇਸਨੂੰ ਚੁਣਨ ਦਾ ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ। TLS 1.3 ਸਮੂਹ ਗੱਲਬਾਤ ਨੂੰ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਅੰਦਰ ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ DH ਫਾਈਲ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਵੇਖਦਾ।
dh none ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੁਰੱਖਿਆ ਦੀ ਘਾਟ ਨਹੀਂ ਹੈ। ਬਦਲ ਬਦਲੀ ਦੀ ਤਾਕਤ ਫਿਰ ਅਸਲ ਵਿੱਚ ਸਹਿਮਤ ਵਕਰ ਅਤੇ ਸੂਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਅਗਲਾ ਕਦਮ ਗੁੰਮ ਫਾਈਲ ਨਹੀਂ ਸਗੋਂ ਇਹ ਵੇਖਣਾ ਹੈ ਕਿ ਧਿਰਾਂ ਨੇ ਕੀ ਚੁਣਿਆ।
ਸੋਧ ਤੋਂ ਪਹਿਲਾਂ ਗੱਲਬਾਤ ਦੀ ਪੁਸ਼ਟੀ
ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਵਿਸਥਾਰਤਾ ਵਧਾਓ ਅਤੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ OpenVPN ਜੋ ਕੰਟਰੋਲ-ਚੈਨਲ ਲਾਈਨ ਛਾਪਦਾ ਹੈ ਉਹ ਪੜ੍ਹੋ। ਇਹ TLS ਸੰਸਕਰਣ ਅਤੇ ਸਹਿਮਤ ਸਾਈਫਰ ਦਾ ਨਾਮ ਦੱਸਦੀ ਹੈ, ਅਤੇ ਸਾਥੀ ਸਰਟੀਫਿਕੇਟ ਦੀ ਕੁੰਜੀ ਕਿਸਮ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ। ਉਹ ਇੱਕੋ ਲਾਈਨ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਿਸਦਾ ਸੰਰਚਨਾ ਫਾਈਲ ਸਿਰਫ਼ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ।
ਜੇ ਇਹ TLS 1.2 ਨਾਲ ECDHE-RSA ਸੂਟ ਅਤੇ RSA ਸਰਟੀਫਿਕੇਟ ਦਿਖਾਉਂਦੀ ਹੈ, ਤਾਂ ਸੰਜੋਗ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜਿਸਦੀ dh none ਉਮੀਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੁਧਾਰਨ ਲਈ ਕੁਝ ਨਹੀਂ। ਜੇ ਇਹ DHE ਸੂਟ ਜਾਂ ਸਾਂਝੇ ਸਾਈਫਰ ਤੋਂ ਬਿਨਾਂ ਹੈਂਡਸ਼ੇਕ ਫੇਲ੍ਹ ਦਿਖਾਉਂਦੀ ਹੈ, ਤਾਂ ਹੱਲ ਸਾਈਫਰ ਨੀਤੀ ਜਾਂ ਕਲਾਇੰਟ ਦੀ ਸਮਰੱਥਾ ਵਿੱਚ ਹੈ, ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਨਹੀਂ।
ਉਸ ਸਭ ਤੋਂ ਪੁਰਾਣੇ ਕਲਾਇੰਟ ਦੀ ਜਾਂਚ ਕਰੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਮਰਥਨ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਕਿਉਂਕਿ ਮੌਜੂਦਾ ਕਲਾਇੰਟ TLS 1.3 'ਤੇ ਸਹਿਮਤ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਪੁਰਾਣਾ TLS 1.2 ਸੂਟ ਤੱਕ ਸੀਮਿਤ ਹੈ। ਜੇ ਸਭ ਤੋਂ ਪੁਰਾਣੇ ਕਲਾਇੰਟ ਵਿੱਚ ਕੋਈ ਓਵਰਲੈਪ ਨਹੀਂ, ਤਾਂ ਜਾਂ ਤਾਂ ਮਨਜ਼ੂਰ ਸੂਟ ਵਧਾਓ ਜਾਂ ਉਸ ਅੰਤ ਬਿੰਦੂ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰੋ।
ਹੈਂਡਸ਼ੇਕ ਫੇਲ੍ਹ ਤੋਂ ਬਚਣ ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਬੰਦ ਨਾ ਕਰੋ। ਫੇਲ੍ਹ ਤੁਹਾਨੂੰ ਦੱਸ ਰਹੀ ਹੈ ਕਿ ਧਿਰਾਂ ਕੁੰਜੀ-ਬਦਲ ਬਦਲੀ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੋ ਸਕੀਆਂ, ਅਤੇ ਜਾਂਚ ਬੰਦ ਕਰਨ ਨਾਲ ਸਮਝੌਤਾ ਹੱਲ ਕੀਤੇ ਬਿਨਾਂ ਪਛਾਣ ਦੀ ਗਾਰੰਟੀ ਹਟ ਜਾਂਦੀ ਹੈ।
ਚੈੱਕਲਿਸਟ: ਸਰਟੀਫਿਕੇਟ RSA ਹੈ, ECDHE ਸੂਟ ਦੀ ਆਗਿਆ ਹੈ, ਲੌਗ ਉਹ ਸੂਟ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਸਮਰਥਿਤ ਸਭ ਤੋਂ ਪੁਰਾਣਾ ਕਲਾਇੰਟ ਵੀ ਇਸ 'ਤੇ ਸਹਿਮਤ ਹੁੰਦਾ ਹੈ? ਜੇ ਚਾਰੇ ਹਾਂ ਹਨ, ਤਾਂ dh none ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।