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

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

ਕਲਾਇੰਟ ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ

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

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

ਕੁੰਜੀ ਸੰਭਾਲ ਦੇ ਤਿੰਨ ਪੱਧਰ

ਪਹਿਲਾ ਪੱਧਰ ਡਿਸਕ ’ਤੇ ਕੁੰਜੀ ਫਾਈਲ ਹੈ। ਇਹ ਡਿਜ਼ਾਈਨ ਨਾਲ ਹੀ ਢੋਣਯੋਗ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ OpenVPN ਪ੍ਰੋਫਾਈਲ ਉੱਥੇ ਹੀ ਰਹਿੰਦੀਆਂ ਹਨ।

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

ਤੀਜਾ ਪੱਧਰ ਸੁਰੱਖਿਆ ਹਾਰਡਵੇਅਰ ਦੇ ਅੰਦਰ ਬਣੀ ਕੁੰਜੀ ਹੈ: TPM, ਸਮਾਰਟ ਕਾਰਡ, SIM ਜਾਂ PIV ਟੋਕਨ। ਉਨ੍ਹਾਂ ਮੌਡਿਊਲਾਂ ਵਿੱਚ ਆਪਣੀ ਬਣਾਈ ਕੁੰਜੀ ਨਿਰਯਾਤ ਕਰਨ ਦਾ ਸਰਕਿਟ ਨਹੀਂ, ਅਤੇ ਦਸਤਖ਼ਤ ਮੌਡਿਊਲ ਦੇ ਅੰਦਰ ਹੀ ਹੁੰਦਾ ਹੈ। ਕੁੰਜੀ ਕਦੇ ਵੀ ਅਜਿਹੀ ਫਾਈਲ ਨਹੀਂ ਬਣਦੀ ਜਿਸ ਦੀ ਕੋਈ ਵੀ ਨਕਲ ਕਰ ਸਕੇ।

Where the key livesCopyableWhat it buys you
Key file inside the profileTriviallyRevocation granularity, nothing more
OS non-exportable key storeHard, not impossibleStops casual profile sharing
TPM or PIV tokenNoBinding the server can rely on

ਉਹ ਸਾਰਣੀ ਤਿੰਨ ਕਤਾਰਾਂ ਵਿੱਚ ਪੂਰੀ ਦਲੀਲ ਹੈ।

easy-rsa ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

ਹਰ ਡਿਵਾਈਸ ਲਈ ਪ੍ਰਮਾਣ ਪੱਤਰ ਜਾਰੀ ਕਰਨਾ ਸਿੱਧਾ ਹੈ। ਉਸੇ CA ਦੇ ਸਾਮ੍ਹਣੇ ਹਰ ਡਿਵਾਈਸ ਲਈ ਵੱਖਰਾ ਆਮ ਨਾਮ ਬਣਾਓ, ਜਿਵੇਂ ./easyrsa build-client-full laptop-a nopass, ਅਤੇ ਹਰ ਡਿਵਾਈਸ ਲਈ ਦੁਹਰਾਓ। ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਆਮ ਨਾਮ ਕਿਸ ਵਿਅਕਤੀ ਅਤੇ ਮਸ਼ੀਨ ਦਾ ਹੈ।

ਰੱਦ ਕਰਨਾ ਵੀ ਉਨਾ ਹੀ ਸਿੱਧਾ ਹੈ: ./easyrsa revoke laptop-a, ./easyrsa gen-crl ਨਾਲ CRL ਦੁਬਾਰਾ ਬਣਾਓ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਰਵਰ ਸੱਚਮੁੱਚ crl-verify ਰਾਹੀਂ ਇਸ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ।

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

ਨਕਲ ਕੀਤੀ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਟਿਕਣ ਵਾਲੇ ਨਿਯੰਤਰਣ

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

ਤੇਜ਼ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਰੱਦ ਕਰਨਾ ਹੀ ਉਹ ਨਿਯੰਤਰਣ ਹੈ ਜੋ ਨਕਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਬਾਕੀ ਸਭ ਰੋਕਥਾਮ ਹੈ।

ਉਹ ਦਾਅਵਾ ਜਿਸ ’ਤੇ ਸਰਵਰ ਸੱਚਮੁੱਚ ਭਰੋਸਾ ਕਰ ਸਕਦਾ ਹੈ

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

ਸੰਬੰਧਿਤ ਲੇਖ