DHE-RSA-AES256-SHA ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਲੌਗ ਲਾਈਨ ਪੂਰੇ ਕਨੈਕਸ਼ਨ ਦਾ ਸਾਰ ਨਹੀਂ ਹੈ। ਇਹ ਉਸ TLS ਹੈਂਡਸ਼ੇਕ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ ਜੋ ਕੰਟਰੋਲ ਚੈਨਲ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਦੇ ਅੰਦਰ ਦੀ ਟ੍ਰੈਫਿਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਨੂੰ VPN ਦਾ ਡੇਟਾ ਸਾਈਫਰ ਦੱਸਣਾ ਉਹ ਗਲਤੀ ਹੈ ਜਿਸ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ।

ਦੋ ਨਤੀਜੇ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਉਹ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਕੰਟਰੋਲ ਚੈਨਲ ਲਈ ਸਹਿਮਤ TLS ਸੂਟ ਹੈ; ਦੂਜਾ ਟਨਲ ਵੱਲੋਂ ਢੋਏ ਜਾਣ ਵਾਲੇ ਪੈਕਟਾਂ ਦਾ ਡੇਟਾ ਸਾਈਫਰ ਹੈ।

ਦੋ ਨਤੀਜੇ, ਦੋ ਸਵਾਲ

ਕੰਟਰੋਲ ਚੈਨਲ ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਸਾਥੀਆਂ ਵਿਚਕਾਰ ਪ੍ਰਬੰਧਨ ਸੁਨੇਹੇ ਢੋਂਦਾ ਹੈ। ਇਸ ਦਾ ਸਾਈਫਰ TLS ਸਟੈਕ ਚੁਣਦਾ ਹੈ, ਇਸ ਲਈ ਨਾਮ TLS ਰੀਤੀਆਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਡੇਟਾ ਚੈਨਲ ਵਰਤੋਂਕਾਰ ਦੀ ਟ੍ਰੈਫਿਕ ਢੋਂਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ OpenVPN ਦੀ ਆਪਣੀ ਸਾਈਫਰ ਗੱਲਬਾਤ ਕਨਫਿਗਰ ਕਰਦੀ ਹੈ।

ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਲਾਈਨ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਰਹੇ ਹੋ। ਇਹ ਕਿ ਟਨਲ ਐਨਕ੍ਰਿਪਟ ਹੈ ਅਤੇ ਇਹ ਕਿ ਹੈਂਡਸ਼ੇਕ ਮਜ਼ਬੂਤ ਹੈ, ਇੱਕੋ ਸਵਾਲ ਨਹੀਂ ਹਨ।

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

TLS ਸੂਟ ਦਾ ਨਾਮ ਇਸ ਦੇ ਆਪਣੇ ਸੰਦਰਭ ਵਿੱਚ ਸਮਝੋ

OpenSSL ਸ਼ੈਲੀ ਦੇ ਇਤਿਹਾਸਕ ਨਾਮ ਵਿੱਚ, ਜਿਵੇਂ DHE-RSA-AES256-SHA, ਹਰ ਹਿੱਸਾ ਵੱਖਰਾ ਫੈਸਲਾ ਦੱਸਦਾ ਹੈ। DHE ਅਲਪਕਾਲਿਕ Diffie-Hellman ਕੁੰਜੀ ਸਮਝੌਤਾ ਹੈ, RSA ਪ੍ਰਮਾਣਿਕਤਾ ਵਿਧੀ ਹੈ, AES256 TLS ਰਿਕਾਰਡਾਂ ਲਈ CBC ਮੋਡ ਵਿੱਚ AES-256 ਹੈ, ਅਤੇ SHA SHA-1 ਅਧਾਰਿਤ ਰਿਕਾਰਡ MAC ਹੈ।

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

OpenSSL ਸੂਟ ਸੰਦਰਭ ਇਹਨਾਂ ਨਾਵਾਂ ਨੂੰ ਉਹਨਾਂ ਦੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨਾਲ ਜੋੜਦਾ ਹੈ ਜੇ ਕੋਈ ਹਿੱਸਾ ਅਣਜਾਣ ਹੋਵੇ।

ਢੋਈ ਟ੍ਰੈਫਿਕ ਲਈ ਡੇਟਾ ਚੈਨਲ ਦਾ ਨਤੀਜਾ ਪੜ੍ਹੋ

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

AES-GCM ਵਰਗਾ AEAD ਸਾਈਫਰ ਆਪਣੀ ਅਖੰਡਤਾ ਜਾਂਚ ਨਾਲ ਲਿਆਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਵੱਖਰਾ ਡੇਟਾ ਚੈਨਲ HMAC ਉਸ ਰਾਹ ਦਾ ਹਿੱਸਾ ਨਹੀਂ।

auth ਨਿਰਦੇਸ਼ TLS, ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਡੇਟਾ ਸਾਈਫਰ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਲਈ ਡਾਈਜੈਸਟ ਚੁਣਦਾ ਹੈ ਜੋ ਅਜੇ ਵੀ ਇੱਕ ਵਰਤਦੇ ਹਨ, ਅਤੇ AEAD ਡੇਟਾ ਸਾਈਫਰ ਨਾਲ ਕਨਫਿਗਰ ਕਰਨ ਲਈ ਵੱਖਰਾ ਡੇਟਾ HMAC ਨਹੀਂ।

ਪਛਾਣ ਜਾਂਚ ਸਾਈਫਰ ਦੇ ਨਤੀਜੇ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

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

ਇਹ ਜਾਂਚਾਂ ਸਮੀਖਿਆ ਨੋਟਾਂ ਵਿੱਚ ਸਾਈਫਰ ਦੇ ਨਤੀਜੇ ਦੇ ਕੋਲ ਰੱਖੋ, ਇਸ ਵਿੱਚ ਮਿਲਾਓ ਨਹੀਂ।

ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਦੇ ਸਹਿਮਤ ਨਤੀਜੇ ਰਿਕਾਰਡ ਕਰੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ