ਕੀ ਅਸਫਲ VPN ਹੈਂਡਸ਼ੇਕ ਸੱਚਮੁੱਚ ਡਾਊਨਗ੍ਰੇਡ ਹਮਲਾ ਹੈ?
ਡਾਊਨਗ੍ਰੇਡ ਹਮਲੇ ਮੌਜੂਦ ਹਨ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਅਸਫਲ ਹੈਂਡਸ਼ੇਕ ਪ੍ਰਸਤਾਵ ਦਾ ਮੇਲ ਨਾ ਹੋਣਾ, ਖਰਾਬ ਰੂਟ ਜਾਂ ਮਿਆਦ ਪੁੱਗੀ ਪ੍ਰੋਫਾਈਲ ਹਨ। ਪਹਿਲਾਂ ਵੇਖੋ ਕੀ ਗੱਲਬਾਤ ਹੋਈ।
ਗਲਤੀ ਨਾਲ ਖ਼ਤਮ ਹੋਣ ਵਾਲਾ ਹੈਂਡਸ਼ੇਕ ਸੁਨੇਹਾ ਵੇਖਣ ਤੱਕ ਹਮਲੇ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ ਇਹ ਗਣਿਤ ਹੁੰਦਾ ਹੈ: ਕੋਈ ਸਾਂਝਾ ਪ੍ਰਸਤਾਵ ਨਹੀਂ, ਮਿਆਦ ਪੁੱਗਿਆ ਸਰਟੀਫਿਕੇਟ, ਜਾਂ ਅਜਿਹਾ ਪੈਕਟ ਜੋ ਕਦੇ ਪਹੁੰਚਿਆ ਹੀ ਨਹੀਂ। ਡਾਊਨਗ੍ਰੇਡ ਹਮਲਾ ਇੱਕ ਖ਼ਾਸ ਚੀਜ਼ ਹੈ: ਹਮਲਾਵਰ ਦੋਵੇਂ ਸਿਰਿਆਂ ਨੂੰ ਉਹਨਾਂ ਦੀ ਚੁਣੀ ਹੋਈ ਨਾਲੋਂ ਕਮਜ਼ੋਰ ਵਿਵਹਾਰ ਵੱਲ ਧੱਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਵੱਖਰੇ ਸਬੂਤ ਛੱਡਦਾ ਹੈ। ਹਰ ਅਸਫਲਤਾ ਨੂੰ ਦੁਰਭਾਵਨਾ ਮੰਨਣ ਨਾਲ ਤੁਸੀਂ ਅਜਿਹੇ ਪੀੜਤ ਦੀ ਭਾਲ ਵਿੱਚ ਜਾਂਦੇ ਹੋ ਜੋ ਸ਼ਾਇਦ ਹੀ ਹੋਵੇ, ਜਦੋਂ ਕਿ ਸੱਚੇ ਡਾਊਨਗ੍ਰੇਡ ਨੂੰ ਕੌਨਫਿਗਰੇਸ਼ਨ ਬੱਗ ਮੰਨਣ ਨਾਲ ਕਮਜ਼ੋਰ ਨਤੀਜਾ ਉੱਥੇ ਹੀ ਰਹਿ ਜਾਂਦਾ ਹੈ। ਦੋਵੇਂ ਗਲਤੀਆਂ ਦੀ ਕੀਮਤ ਵੱਖਰੀ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਸਸਤੇ ਵਿੱਚ ਸੁਧਾਰੀ ਜਾ ਸਕਦੀ ਹੈ।
ਡਾਊਨਗ੍ਰੇਡ ਹਮਲਾ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ
ਮਕਸਦ ਸਾਈਫਰ ਤੋੜਨਾ ਨਹੀਂ ਅਤੇ ਚਾਬੀ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਨਹੀਂ। ਮਕਸਦ ਗੱਲਬਾਤ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਪ੍ਰਭਾਵਿਤ ਕਰਨਾ ਹੈ ਕਿ ਦੋਵੇਂ ਧਿਰਾਂ ਕਿਸੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਜਾਂ ਕਮਜ਼ੋਰ ਐਲਗੋਰਿਦਮ ਉੱਤੇ ਰੁਕ ਜਾਣ ਜਿਸਨੂੰ ਹਮਲਾਵਰ ਸੰਭਾਲ ਸਕੇ, ਜਾਂ ਇੱਕ ਧਿਰ ਮੰਨ ਲਵੇ ਕਿ ਦੂਜੀ ਸਿਰਫ਼ ਉਸੇ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ।
ਬਦਲਦਾ ਸਮਝੌਤਾ ਹੈ, ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ। ਜੇ ਹਮਲਾਵਰ ਫੜੇ ਬਿਨਾਂ ਪੇਸ਼ਕਸ਼ ਬਦਲ ਸਕਦਾ ਹੈ, ਤਾਂ ਧਿਰਾਂ ਅਜੇ ਵੀ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਹਮਲਾਵਰ ਨੂੰ ਪਸੰਦ ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ। ਇਸੇ ਲਈ ਦਿਲਚਸਪ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਗੱਲਬਾਤ ਆਪ ਹੀ ਅਖੰਡਤਾ ਸੁਰੱਖਿਆ ਵਿੱਚ ਹੈ।
ਗੱਲਬਾਤ ਨੂੰ ਆਪ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹੈ
TLS 1.3 ਇਸ ਸੁਰੱਖਿਆ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ। ਨਵਾਂ ਸੰਸਕਰਣ ਪੇਸ਼ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਚੁੱਪਚਾਪ ਪਿੱਛੇ ਹਟੇ ਸਰਵਰ ਨੂੰ ਪਛਾਣ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਰਵਰ ਦਾ ਬੇਤਰਤੀਬ ਮੁੱਲ 1.2 ਜਾਂ ਇਸ ਤੋਂ ਹੇਠਾਂ ਗੱਲਬਾਤ ਕਰਦਿਆਂ ਇੱਕ ਨਿਸ਼ਚਿਤ ਪੈਟਰਨ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਇਹ ਵੇਖ ਕੇ ਰੁਕਣਾ ਪੈਂਦਾ ਹੈ। ਪੂਰਾ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਵੀ ਆਖ਼ਰੀ ਸੁਨੇਹਿਆਂ ਨਾਲ ਢਕਿਆ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਗੱਲਬਾਤ ਵਿੱਚ ਕਿਤੇ ਵੀ ਬਦਲਾਅ ਬਾਅਦ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਚੁੱਪਚਾਪ ਲੰਘਦਾ ਨਹੀਂ।
ਪੁਰਾਣੇ ਪ੍ਰੋਟੋਕੋਲ ਸੰਸਕਰਣਾਂ ਦੀਆਂ ਕਹਾਣੀਆਂ ਕਮਜ਼ੋਰ ਸਨ, ਅਤੇ ਇਸੇ ਲਈ ਫਾਲਬੈਕ ਨਿਯਮ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਉਸੇ ਕੌਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ TLS 1.0 ਐਂਡਪੌਇੰਟ ਡਾਊਨਗ੍ਰੇਡ ਹਮਲਾ ਨਹੀਂ ਹੈ; ਇਹ ਮਨਜ਼ੂਰ ਨਤੀਜਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਆਪ ਮਨਜ਼ੂਰ ਕਰਨਾ ਚੁਣਿਆ। ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਕਮਜ਼ੋਰ ਨਤੀਜਾ ਕਿਸੇ ਸੁਰੱਖਿਅਤ ਫ਼ੈਸਲੇ ਤੋਂ ਆਇਆ ਜਾਂ ਕਿਸੇ ਅਸੁਰੱਖਿਅਤ ਰਾਹ ਤੋਂ ਜਿਸਨੂੰ ਕੋਈ ਵਿਚੋਲਾ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਸੀ। ਇਸ ਤਰ੍ਹਾਂ ਕਹਿਣ ਨਾਲ ਜ਼ਿਆਦਾਤਰ ਘਟਨਾਵਾਂ ਕੌਨਫਿਗਰੇਸ਼ਨ ਦੇ ਸਵਾਲ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
IKEv2 ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ ਪਰ ਉਸੇ ਵਿਚਾਰ ਉੱਤੇ ਟਿਕਿਆ ਹੈ। ਪ੍ਰਸਤਾਵ ਉਸ ਅਦਲਾ-ਬਦਲੀ ਵਿੱਚ ਜਾਂਦਾ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਦੋਵੇਂ ਧਿਰਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਐਲਗੋਰਿਦਮ ਦੁਬਾਰਾ ਲਿਖਣ ਵਾਲਾ ਵਿਚਕਾਰਲਾ ਬਾਕਸ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਸੇਧ ਦੇਣ ਦੀ ਥਾਂ ਤੋੜਦਾ ਹੈ। OpenVPN ਦਾ ਕੰਟਰੋਲ ਚੈਨਲ TLS ਨਾਲ ਆਪਣੀ ਗੱਲਬਾਤ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਉਸੇ ਚੈਨਲ ਨਾਲ ਡੇਟਾ ਚੈਨਲ ਦੇ ਸਾਈਫਰ ਤੈਅ ਕਰਦਾ ਹੈ, ਇਸੇ ਲਈ ਕੰਟਰੋਲ ਚੈਨਲ ਦੀ ਲੌਗ ਲਾਈਨ ਦਿਲਚਸਪ ਹੈ।
ਕੌਨਫਿਗਰ ਕੀਤੀ ਅਨੁਕੂਲਤਾ ਹਮਲਾ ਨਹੀਂ ਹੈ
ਪ੍ਰਬੰਧਕ ਦਸਤਾਵੇਜ਼ੀ ਕਲਾਇੰਟ ਦੇ ਸਮਰਥਨ ਲਈ ਜਾਣ-ਬੁੱਝ ਕੇ ਪੁਰਾਣੇ ਵਿਕਲਪ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹ ਫ਼ੈਸਲਾ ਕੌਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਦਿਖਦਾ ਹੈ। ਹਮਲਾਵਰ ਉਹ ਕੌਨਫਿਗਰੇਸ਼ਨ ਨਹੀਂ ਬਣਾ ਸਕਦਾ; ਉਹ ਸਿਰਫ਼ ਉਸ ਰਾਹ ਦਾ ਫ਼ਾਇਦਾ ਉਠਾ ਸਕਦਾ ਹੈ ਜੋ ਉਸਨੂੰ ਪੇਸ਼ਕਸ਼ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦਿੰਦਾ ਹੈ।
ਖ਼ਤਰਨਾਕ ਮੁਰੰਮਤ ਉਹ ਹੈ ਜੋ ਫ਼ਰਕ ਦਾ ਸਬੂਤ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਹਰ ਪੁਰਾਣਾ ਵਿਕਲਪ ਸਮਰੱਥ ਕਰਨਾ, ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਬੰਦ ਕਰਨਾ ਜਾਂ ਗਲਤੀ ਗ਼ਾਇਬ ਕਰਨ ਲਈ ਕੋਈ ਵੀ ਸਾਈਫਰ ਸਵੀਕਾਰ ਕਰਨਾ ਉਸ ਦਾਇਰੇ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਐਂਡਪੌਇੰਟ ਸਹਿਮਤ ਹੋਵੇਗਾ, ਅਤੇ ਉਹ ਜਾਂਚਾਂ ਹਟਾ ਦਿੰਦਾ ਹੈ ਜੋ ਕਮਜ਼ੋਰ ਨਤੀਜੇ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀਆਂ ਸਨ।
ਜੇ ਇੱਕ ਪੁਰਾਣਾ ਵਿਕਲਪ ਰੱਖਣਾ ਹੀ ਪਵੇ, ਤਾਂ ਕਾਰਨ ਅਤੇ ਕਲਾਇੰਟ ਕੌਨਫਿਗਰੇਸ਼ਨ ਟਿੱਪਣੀ ਵਿੱਚ ਲਿਖੋ, ਫਿਰ ਵਿਕਲਪ ਨੂੰ ਉਸੇ ਪ੍ਰੋਫਾਈਲ ਤੱਕ ਸੀਮਿਤ ਕਰੋ ਜਿਸਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ। ਇੱਕ ਸਰੋਤੇ ਤੱਕ ਸੀਮਿਤ ਅਨੁਕੂਲਤਾ ਅਪਵਾਦ ਆਡਿਟ ਕਰਨ ਯੋਗ ਹੈ; ਸਭ ਥਾਂ ਲਾਗੂ ਕੀਤਾ ਅਪਵਾਦ ਸਿਰਫ਼ ਕਮਜ਼ੋਰ ਡਿਫ਼ਾਲਟ ਹੈ ਜਿਸਨੂੰ ਕਿਸੇ ਨੂੰ ਯਾਦ ਨਹੀਂ ਕਿ ਉਸਨੇ ਚੁਣਿਆ ਸੀ।
ਕਾਰਨ ਦਾ ਨਾਮ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲਤਾ ਪੜ੍ਹੋ
ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਸਹੀ ਗਲਤੀ ਸਤਰ, ਕਲਾਇੰਟ ਤੇ ਸਰਵਰ ਸੰਸਕਰਣ ਅਤੇ ਸਮਾਂ ਸੰਭਾਲੋ। ਫਿਰ ਵਰਗੀਕਰਨ ਕਰੋ: ਧਿਰਾਂ ਪ੍ਰਸਤਾਵ ਉੱਤੇ ਸਹਿਮਤ ਨਹੀਂ ਸਨ, ਪੈਕਟ ਰਾਹ ਅਸਫਲ ਹੋਇਆ, ਜਾਂ ਇੱਕ ਧਿਰ ਨੇ ਉਹ ਪੈਰਾਮੀਟਰ ਨਾਮਨਜ਼ੂਰ ਕੀਤਾ ਜੋ ਕਦੇ ਸਵੀਕਾਰ ਕਰਦੀ ਸੀ?
ਪ੍ਰਸਤਾਵ ਦਾ ਮੇਲ ਨਾ ਹੋਣਾ ਆਮ ਤੌਰ ’ਤੇ ਦੋਸ਼ੀ ਸੰਸਕਰਣਾਂ ਜਾਂ ਐਲਗੋਰਿਦਮ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਅਤੇ ਹਰ ਵਾਰ ਉਸੇ ਬਿੰਦੂ ’ਤੇ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਰੂਟਿੰਗ ਜਾਂ MTU ਸਮੱਸਿਆ ਰੁਕ ਜਾਂਦੀ ਹੈ ਜਾਂ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਅਕਸਰ ਨੈੱਟਵਰਕ ਅਨੁਸਾਰ ਬਦਲਦੀ ਹੈ। ਮਿਆਦ ਪੁੱਗਿਆ ਸਰਟੀਫਿਕੇਟ ਗੱਲਬਾਤ ਦੀ ਨਹੀਂ, ਜਾਂਚ ਦੀ ਗਲਤੀ ਦਿੰਦਾ ਹੈ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਹਮਲਾਵਰ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ। ਪਹਿਲੀ ਅਸਫਲਤਾ ’ਤੇ ਦੁਰਭਾਵਨਾਪੂਰਨ ਕਾਰਨ ਮੰਨ ਲੈਣਾ ਹੀ ਗਲਤੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਉਸ ਨਿਸ਼ਚਿਤ ਬੱਗ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੈ ਜੋ ਕੱਲ੍ਹ ਫਿਰ ਅਸਫਲ ਹੋਵੇਗਾ।
ਅਸਲ ਵਿੱਚ ਕੀ ਚੁਣਿਆ ਗਿਆ, ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਕਿਸੇ ਵੀ ਸੁਧਾਰ ਤੋਂ ਬਾਅਦ, ਕਨੈਕਸ਼ਨ ਆ ਗਿਆ ਮੰਨਣ ਦੀ ਥਾਂ ਤੈਅ ਨਤੀਜਾ ਪੜ੍ਹੋ। ਜਾਂਚ ਹਟਾਏ ਜਾਣ ਕਰਕੇ ਸਫਲ ਹੋਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਹੀ ਉਹ ਨਤੀਜਾ ਹੈ ਜਿਸ ਤੋਂ ਤੁਸੀਂ ਬਚਣਾ ਚਾਹੁੰਦੇ ਸੀ। ਹੇਠਾਂ ਦਿੱਤੇ ਦੋ ਕਮਾਂਡ TLS-ਸਾਹਮਣੇ ਐਂਡਪੌਇੰਟ ਲਈ ਚੁਣਿਆ ਸੰਸਕਰਣ ਅਤੇ ਸਾਈਫਰ, ਅਤੇ OpenVPN ਸਰਵਰ ਲੌਗ ਦੀ ਕੰਟਰੋਲ ਚੈਨਲ ਲਾਈਨ ਦਿਖਾਉਂਦੇ ਹਨ।
openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5ਨਤੀਜੇ ਦੀ ਤੁਲਨਾ ਉਸ ਕੌਨਫਿਗਰੇਸ਼ਨ ਨਾਲ ਕਰੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਸੀ, ਹੁਣ ਜੋ ਜੁੜ ਰਿਹਾ ਹੈ ਉਸ ਨਾਲ ਨਹੀਂ। ਜੇ ਚੁਣਿਆ ਸੰਸਕਰਣ ਮਨਜ਼ੂਰ ਘੱਟੋ-ਘੱਟ ਤੋਂ ਪੁਰਾਣਾ ਹੈ, ਤਾਂ ਪ੍ਰੋਫਾਈਲ ਜਾਂ ਫਾਲਬੈਕ ਸੂਚੀ ਵੇਖਣ ਦੀ ਥਾਂ ਹੈ, ਅਤੇ ਜਵਾਬ ਉਹ ਸੂਚੀ ਸੁਧਾਰਨਾ ਹੈ, ਹਮਲਾ ਐਲਾਨ ਕੇ ਆਲੇ-ਦੁਆਲੇ ਸਭ ਕੁਝ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਨਹੀਂ।