SSTP ਅਤੇ SSL 3.0: ਲੇਬਲ ਬਨਾਮ ਤੈਅ ਕੀਤਾ ਸੰਸਕਰਣ

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

ਇੱਕੋ ਸਵਾਲ ਦੇ ਦੋ ਜਵਾਬ

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

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

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

ਉਹ ਸੰਸਕਰਣ ਪੜ੍ਹੋ ਜੋ ਸੇਵਾ ਅਸਲ ਵਿੱਚ ਚੁਣਦੀ ਹੈ

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

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

ਰਿਕਾਰਡ ਫ਼ੀਲਡ ਨੂੰ ਗੱਲਬਾਤ ਤੋਂ ਵੱਖ ਕਰੋ

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

ਉਹੀ ਦਸਤਾਵੇਜ਼ ਪ੍ਰੋਟੋਕੋਲ ਬਾਰੇ ਸਪਸ਼ਟ ਹੈ: SSL 3.0 ਵਰਤਿਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਇਸ 'ਤੇ ਗੱਲਬਾਤ ਜਾਂ ਵਾਪਸੀ ਮਨਾਹੀ ਹੈ। ਕਾਰਨ ਉਹ ਟੁੱਟੀ CBC ਬਣਤਰ ਹੈ ਜਿਸਦਾ POODLE ਹਮਲੇ ਨੇ ਫ਼ਾਇਦਾ ਉਠਾਇਆ, ਅਤੇ ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਗੁਣ ਹੈ, ਕਿਸੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸੰਰਚਨਾ ਨਹੀਂ।

ਇਸ ਲਈ “ਇਹ ਕੰਮ ਭਾਰ ਸ਼ਾਇਦ ਸ਼ੋਸ਼ਣ ਕਰਨਾ ਔਖਾ ਹੈ” SSL 3.0 ਸਮਰੱਥ ਰੱਖਣ ਦਾ ਤਰਕ ਨਹੀਂ। ਲੋੜ ਪ੍ਰੋਟੋਕੋਲ ਹਟਾਉਣਾ ਹੈ, ਕਿਸੇ ਇੱਕ ਪ੍ਰਦਰਸ਼ਨੀ 'ਤੇ ਬਹਿਸ ਜਿੱਤਣਾ ਨਹੀਂ।

SSL 3.0 ਨੂੰ ਅਜਿਹੀ ਨੀਤੀ ਨਾਲ ਹਟਾਓ ਜਿਸਦਾ ਤੁਸੀਂ ਬਚਾਅ ਕਰ ਸਕੋ

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

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

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

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

ਬਦਲਾਅ ਨੂੰ ਨਵੇਂ ਕਨੈਕਸ਼ਨਾਂ ਨਾਲ ਸਵੀਕਾਰ ਕਰੋ

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

ਯਾਦ ਰੱਖੋ ਹੈਂਡਸ਼ੇਕ ਕੀ ਨਹੀਂ ਢਕਦਾ। SSTP TLS ਪਰਤ ਤੋਂ ਬਾਅਦ PPP ਪ੍ਰਮਾਣਿਕਤਾ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਆਧੁਨਿਕ ਪ੍ਰੋਟੋਕੋਲ ਸੰਸਕਰਣ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜਾ ਵਰਤੋਂਕਾਰ ਅਧਿਕ੍ਰਿਤ ਹੋਇਆ ਜਾਂ ਸੈਸ਼ਨ ਕਿਹੜੇ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਇਹ ਵੱਖਰੇ ਨਿਯੰਤਰਣ ਹਨ ਵੱਖਰੇ ਸਬੂਤਾਂ ਨਾਲ।

ਨਤੀਜਾ ਸੇਵਾ, ਬੈਕਐਂਡ, ਮਨਜ਼ੂਰ ਨੀਤੀ ਅਤੇ ਨਿਰੀਖਤ ਸੰਸਕਰਣ ਵਜੋਂ ਲਿਖੋ। ਅਜਿਹਾ ਰਿਕਾਰਡ ਸੁਰੱਖਿਆ ਸਵਾਲ ਦਾ ਸਹੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜੋ ਨਾ ਲੇਬਲ ਵਾਲਾ ਤਰਕ ਦਿੰਦਾ ਹੈ ਨਾ ਅਸੁਵਿਧਾ ਵਾਲਾ ਤਰਕ।