Martin Hellman ਨੇ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਵਿਕਸਿਤ ਕੀਤਾ ਕਿ ਅਜਾਣੇ ਲੋਕ ਵੀ ਵਿਪਰੀਤ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਗੁਪਤ ਸਾਂਝੇ ਕਰ ਸਕਣ। ਦੇਖੋ ਇਹ TLS, VPN ਅਤੇ ਆਧੁਨਿਕ ਭਰੋਸੇ ਲਈ ਕਿਵੇਂ ਮੂਲ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਇੰਟਰਨੈੱਟ 'ਤੇ ਸੁਨੇਹਾ ਭੇਜਦੇ ਹੋ, ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਤਰ੍ਹਾਂ-ਤਰ੍ਹਾਂ ਦੇ ਨੈੱਟਵਰਕਾਂ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੇ ਅਤੇ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਜਾਂਚ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਮੂਲ ਸਮੱਸਿਆ ਇਹ ਹੈ: ਤੁਸੀਂ ਇਕ ਨਿੱਜੀ ਗੱਲਬਾਤ ਚਾਹੁੰਦੇ ਹੋ, ਪਰ ਜਿਸ "ਕਮਰੇ" ਵਿੱਚ ਤੁਸੀਂ ਗੱਲ ਕਰ ਰਹੇ ਹੋ ਉਹ ਜਨਤਕ ਹੈ।
ਇੱਕ ਵਿਪਰੀਤ ਨੈਟਵਰਕ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਕਿਸੇ ਦੁਰਾਚਾਰੀ ਦੁਆਰਾ ਚਲਾਇਆ ਹੋਇਆ ਨਹੀਂ ਹੁੰਦਾ। ਇਸਦਾ ਮਤਲਬ ਸਿਰਫ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਅਤੇ ਦੂਜੇ ਵਿਅਕਤੀ ਦਰਮਿਆਨ ਰਾਹੀਆਂ ਉਹ ਹਨ ਜੋ ਤੁਹਾਡੇ ਭੇਜੇ ਹੋਏ ਡੇਟਾ ਨੂੰ ਦੇਖ, ਬਦਲ ਜਾਂ ਰੀਰੂਟ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਸੋਚੋ:
ਖੁੱਲੇ ਨੈੱਟਵਰਕ 'ਤੇ, "ਭਰੋਸਾ" ਇਕ ਡਿਫੌਲਟ ਸੈਟਿੰਗ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ ਤੁਸੀਂ ਗੁਪਤ ਜਾਣਕਾਰੀਆਂ ਸਾਫ ਟੈਕਸਟ ਵਿੱਚ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਇਹ ਅਸਲ ਵਿੱਚ ਹਰ ਇੱਕ ਰੁਕਾਵਟ ਨੂੰ ਤੁਹਾਡੇ ਗੁਪਤਾਂ ਦੀਆਂ ਨਕਲਾਂ ਦੇ ਦੇਣਾ ਹੈ।
ਕਈ ਦਹਾਕਿਆਂ ਤੱਕ, ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ ਦਾ ਇੱਕ ਬੜਾ ਬੋਟਲਨੈਕ ਇਹ ਸੀ: ਇੰਕ੍ਰਿਪਸ਼ਨ ਵਰਤਣ ਲਈ ਦੋਨਾਂ ਪੱਖਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸਾਂਝੀ ਗੁਪਤ ਕੁੰਜੀ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ। ਪਰ ਜੇ ਨੈੱਟਵਰਕ ਨਿਗਰਾਨੀ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਉਹ ਗੁਪਤ ਕੁੰਜੀ ਪਹਿਲਾਂ ਕਿਵੇਂ ਸਾਂਝੀ ਕਰੋ?
ਇਹੋ ਜਿਹੇ ਸਮੇਂ ਵਿੱਚ Martin Hellman (Whitfield Diffie ਅਤੇ Ralph Merkle ਦੇ ਸਹਿਯੋਗ ਨਾਲ) ਨੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦਾ ਰੁਖ ਬਦਲ ਦਿੱਤਾ। ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਨੇ ਸੌਖਾ ਕਰ ਦਿੱਤਾ ਕਿ ਦੋ ਪੱਖ ਇਕ ਅਣ-ਸੁਰੱਖਿਅਤ ਚੈਨਲ ਰਾਹੀਂ ਵੀ ਸਾਂਝੀ ਗੁਪਤ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਨ—ਬਿਨਾਂ ਪਹਿਲਾਂ ਮਿਲੇ ਹੋਣ ਦੇ।
ਤੁਸੀਂ ਇਸ ਸੋਚ 'ਤੇ ਹਰ ਵਾਰੀ ਭਰੋਸਾ ਕਰਦੇ ਹੋ ਜਦੋਂ ਤੁਸੀਂ HTTPS, ਕਈ ਸੁਰੱਖਿਅਤ ਮੇਸੇਜਿੰਗ ਐਪਸ ਅਤੇ VPN ਵਰਤਦੇ ਹੋ।
ਇਹ ਲੇਖ ਭਾਰ ਭਰੇ ਗਣਿਤ 'ਤੇ ਨਹੀਂ, ਸਿਧਾਂਤਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਰਹੇਗਾ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਮਝ ਸਕੋ ਕਿ ਜਦੋਂ ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ "ਸੁਰੱਖਿਅਤ" ਦਿਖਾਉਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਇਹ ਭਰੋਸਾ ਕਿਵੇਂ ਬਣਦਾ ਹੈ।
ਜਦੋਂ ਤੱਕ "ਪਬਲਿਕ ਕੀ" ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਹੋਈ, ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਯੋਗਤਮਕ ਇੰਕ੍ਰਿਪਸ਼ਨ ਸੀਮੈਟ੍ਰਿਕ ਸੀ: ਦੋਨਾਂ ਪੱਖ ਉਹੀ ਗੁਪਤ ਕੁੰਜੀ ਵਰਤਦੇ ਸਨ। ਜੇ ਤੁਸੀਂ ਕਦੇ ਕਿਸੇ ਫਾਇਲ ਨੂੰ ਪਾਸਵਰਡ ਨਾਲ ਖੋਲ੍ਹਿਆ ਹੈ, ਤਾਂ ਇਹੀ ਮੂਲ ਵਿਚਾਰ ਹੈ।
ਲੰਬੇ ਸਮੇਂ ਤੱਕ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦੋ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦੀ ਸੀ: ਸਾਈਫਰਾਂ ਨੂੰ ਓਖਾ ਬਣਾਉਣਾ ਅਤੇ ਕੁੰਜੀਆਂ ਦਾ ਸੰਭਾਲ ਕਰਨਾ।
ਸੀਮੇਟ੍ਰਿਕ ਇੰਕ੍ਰਿਪਸ਼ਨ ਇਸ ਲਈ ਆਕਰਸ਼ਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵੱਡੇ ਡੇਟੇ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਸੀ ਕਾਰਨ ਅੱਜ ਵੀ ਜ਼ਿਆਦਾਤਰ ਸੁਰੱਖਿਅਤ ਸਬੰਧਾਂ ਦੀ ਬੁਨਿਆਦ ਸੀਮੇਟ੍ਰਿਕ ਹੈ।
ਪਰ ਇਸਦਾ ਸਖ਼ਤ ਲਾਜ਼ਮੀ ਸ਼ਰਤ ਹੈ: ਦੋਨਾਂ ਪੱਖਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੁੰਜੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹਿੱਸਾ ਅਕਸਰ ਇੰਕ੍ਰਿਪਟ ਕਰਨ ਤੋਂ ਨਹੀਂ, ਸੈਟਅਪ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਐਲਿਸ ਬੌਬ ਨੂੰ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਇੱਕ ਇੰਕ੍ਰਿਪਟ ਕੀਤਾ ਸੁਨੇਹਾ ਭੇਜਣਾ ਚਾਹੁੰਦੀ ਹੈ ਅਤੇ ਨੈੱਟਵਰਕ ਨਿਗਰਾਨੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਐਲਿਸ ਸਿੱਧਾ ਸੀਮੇਟ੍ਰਿਕ ਕੁੰਜੀ ਬੌਬ ਨੂੰ ਭੇਜ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਕੋਈ ਨਜ਼ਰ ਰੱਖਣ ਵਾਲਾ ਉਸਦੀ ਨਕਲ ਵੀ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਉਹ ਪਹਿਲਾਂ ਹੀ ਕੁੰਜੀ ਸਾਂਝੀ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਉਹਨੂੰ ਦਿੱਤੀ ਜਾਣ ਲਈ ਹੋਰ ਕੋਈ ਸੁਰੱਖਿਅਤ ਚੈਨਲ ਚਾਹੀਦਾ ਹੈ।
ਇਸ ਨਾਲ ਇੱਕ ਚੱਕਰ ਬਣ ਜਾਂਦਾ ਹੈ:
ਇਹ ਉਹੀ ਹੈ ਜਿਵੇਂ ਕਿਸੇ ਫੋਨ ਕਾਲ 'ਤੇ ਪਾਸਵਰਡ ਸਹਿਮਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਜਿਸ ਦੀ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਰਿਕਾਰਡ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਉੱਚੀ ਅਵਾਜ਼ ਵਿੱਚ ਪਾਸਵਰਡ ਦੱਸਣਾ ਮਕਸਦ ਨੂੰ ਨਰੁਸਤ ਕਰ ਦਿੰਦਾ ਹੈ। ਖ਼ਤ ਰਾਹੀ ਪੋਸਟ ਕਾਰਜ ਕਰ ਸਕਦੀ ਹੈ—ਪਰ ਸਿਰਫ ਜੇ ਤੁਸੀਂ ਡਾਕ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋ ਅਤੇ ਕੋਈ ਲੜੀ ਨ ਸਮੇਤ ਖੋਲ੍ਹਦਾ ਨਹੀਂ।
ਛੋਟੇ ਪੱਧਰ 'ਤੇ, ਹਨੀ-ਕੁਰਿਰੀਅਰ, ਪਹਿਲਾਂ-ਹੀ-ਸਾਂਝੇ ਕੋਡਬੁੱਕ, ਹਾਰਡਵੇਅਰ ਉਪਕਰਣ ਜਾਂ ਕਬਜ਼ੇ ਵਾਲੇ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਇਸਨੂੰ ਹੱਲ ਕਰਦੇ ਸਨ। ਪਰ ਇੰਟਰਨੈੱਟ ਪੱਧਰ 'ਤੇ—ਜਿੱਥੇ ਅਜਾਣੇ ਕੰਪਿਊਟਰ ਸਕਿੰਟਰ ਸਕਿੰਕਿਆਂ ਨੂੰ ਸਕੈਕਡਨ 'ਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਜੁੜਨਾ ਚਾਹੀਦਾ—ਇਹ ਤਰੀਕਾ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।
ਬਿਨਾਂ ਕਿਸੇ ਤਰੀਕੇ ਦੇ ਜੋ ਖੁੱਲੇ ਨੈੱਟਵਰਕ 'ਤੇ ਗੁਪਤ ਬਣਾਉਂਦਾ ਹੋਵੇ, ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ ਉਨ੍ਹਾਂ ਵਾਤਾਵਰਣਾਂ ਤੱਕ ਸੀਮਿਤ ਸੀ ਜਿੱਥੇ ਕੁੰਜੀਆਂ ਪਹਿਲਾਂ ਹੀ ਵੰਡੀਆਂ ਜਾ ਸਕਦੀਆਂ ਸਨ। ਇਸਦਾ ਨਤੀਜਾ:
ਇਹ ਸਾਂਝੀ-ਗੁਪਤ ਰੁਕਾਵਟ ਉਹ ਕੰਧ ਸੀ ਜਿਸਨੂੰ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਵਾਲੀਆਂ ਸੋਚਾਂ ਨੇ (Martin Hellman ਦੇ ਯੁੱਗ ਨਾਲ ਸੰਬੰਧਿਤ) ਤੋੜਿਆ।
Martin Hellman ਇਕ ਕੰਪਿਊਟਰ ਵਿਗਿਆਨੀ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਨਾਮ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਵਿੱਚ ਇਕ ਮੋੜ ਵਾਲੇ ਬਿੰਦੂ ਨਾਲ ਨਜ਼ਦੀਕੀ ਰੂਪ ਨਾਲ ਜੁੜਿਆ ਹੈ: ਅਜਾਣੇ ਲੋਕਾਂ ਨੂੰ ਖੁੱਲੇ ਨੈੱਟਵਰਕ 'ਤੇ ਗੁਪਤ ਸਥਾਪਿਤ ਕਰਨ ਯੋਗ ਬਣਾਉਣਾ। ਹੁਣ ਇਹ ਆਮ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਸਨੇ ਉਹ ਪ੍ਰਾਇਕਟੀਕਲ ਸਮੱਸਿਆ ਸਿੱਧੀ ਕੀਤੀ ਜੋ ਪਹਿਲੇ ਨੈੱਟਵਰਕ ਤੰਤਰ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕੇ।
Hellman ਦੇ ਯੁੱਗ ਤੋਂ ਪਹਿਲਾਂ, ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ ਅਕਸਰ ਪਹਿਲਾਂ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸਾਂਝੀ ਗੁਪਤ ਦੀ ਧਾਰਣਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਸੀ: ਦੋ ਪੱਖਾਂ ਨੂੰ ਮਿਲਣਾ ਪੈਂਦਾ ਸੀ ਜਾਂ ਇੱਕ ਭਰੋਸੇਯੋਗ ਕੋਰੀਏਅਰ ਵਰਤਣਾ ਪੈਂਦਾ ਸੀ। ਇਹ ਛੋਟੀ ਗ੍ਰੁੱਪਾਂ ਲਈ ਕੰਮ ਕਰਦਾ, ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਮਿਲੀਅਨਾਂ ਡਿਵਾਈਸਾਂ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਨੈਕਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਪੱਧਰ-ਅਨੁਕੂਲਤਾ ਨਾਲ ਨਹੀਂ ਸੀ।
Hellman ਦਾ ਮੁੱਖ ਯੋਗਦਾਨ— Diffie–Hellman ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਦੇ ਰਾਹੀਂ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ—ਨੇ ਸਵਾਲ ਨੂੰ ਬਦਲ ਦਿੱਤਾ: "ਅਸੀਂ ਕੁੰਜੀ ਕਿਵੇਂ ਲਿਜਾਂਦੇ ਹਾਂ?" ਦੀ ਥਾਂ "ਅਸੀਂ ਕਿਵੇਂ ਨਵੀਂ ਸਾਂਝੀ ਕੁੰਜੀ ਬਣਾਉਣੀ ਹੈ ਜਦੋਂ ਕੋਈ ਸੁਣ ਰਿਹਾ ਹੋਵੇ?".
ਬ੍ਰੇਕਥਰੂ ਸਿਰਫ਼ ਅਧਾਰਭੂਤ ਵਿਚਾਰ ਨਹੀਂ ਸੀ। ਇਹ ਇੱਕ ਵਰਤੋਂਯੋਗ ਇਮਾਰਤੀ ਥੀ ਜਿਸਨੂੰ ਅਸਲ ਸਿਸਟਮਾਂ ਨੇ ਲਾਗੂ ਕਰ ਸਕਿਆ। ਇਸ ਨਾਲ ਅਕਾਦਮਿਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਅਤੇ ਨੈੱਟਵਰਕ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਚਕਾਰ ਦਾ ਫਾਸਲਾ ਘੱਟ ਹੋ ਗਿਆ: ਤੁਸੀਂ ਐਸੇ ਪ੍ਰੋਟੋਕੋਲ ਡਿਜ਼ਾਇਨ ਕਰਨ ਲਾ ਸਕਦੇ ਹੋ ਜੋ ਨੈੱਟਵਰਕ ਨੂੰ ਨਿਗਰਾਨੀ ਵਾਲਾ ਮੰਨਦੇ ਹੋ ਅਤੇ ਫਿਰ ਵੀ ਗੁਪਤਤਾ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ।
ਸੰਗ੍ਰਹਿਤ ਰੂਪ ਵਿੱਚ, "ਪਬਲਿਕ-ਕੀ" ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕੁਝ ਜਾਣਕਾਰੀ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਪ੍ਰਕਾਸ਼ਤ ਕਰ ਸਕਦੇ ਹੋ (ਤੁਹਾਡਾ "ਪਬਲਿਕ" ਹਿੱਸਾ) ਜਦਕਿ ਇਸ ਨਾਲ ਸੰਬੰਧਿਤ ਇੱਕ ਨਿੱਜੀ ਰਾਜ਼ ਰੱਖਦੇ ਹੋ। ਹੋਰ ਲੋਕ ਤੁਹਾਡੇ ਪਬਲਿਕ ਹਿੱਸੇ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਹਾਡੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰ ਸਕਦੇ ਹਨ—ਬਿਨਾਂ ਤੁਹਾਡੀ ਨਿੱਜੀ ਕੁੰਜੀ ਜਾਣਦੇ ਹੋਏ। ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਵਿੱਚ, ਇਹ ਪਬਲਿਕ ਜਾਣਕਾਰੀ ਦੋ ਪੱਖਾਂ ਨੂੰ ਸਾਂਝੀ ਸੈਸ਼ਨ ਕੁੰਜੀ 'ਤੇ 'ਸਹਿਮਤ' ਕਰਨ ਦਿੰਦਾ ਹੈ, ਨਾ ਕਿ ਉਸ ਨੂੰ 'ਭੇਜਦਾ' ਹੈ।
ਇਹ ਵੀ ਮਹੱਤਵਪੂਰਣ ਸੰਦਰਭ ਹੈ ਕਿ ਇਹ ਇਕ ਐਕਲੌਤਾ ਉਪਕਾਰ ਨਹੀਂ ਸੀ: Ralph Merkle ਵਰਗੇ ਸਮਕਾਲੀ ਵਿਦਵਾਨਾਂ ਨੇ ਹੋਰ ਮਿਲਦੇ-ਜੁਲਦੇ ਰਾਹਾਂ ਨੂੰ ਖੋਜਿਆ, ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਕਮਿьюਨਿਟੀ ਨੇ ਇਹਨਾਂ ਵਿਚਾਰਾਂ ਨੂੰ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਪ੍ਰੀਖਿਆ ਅਤੇ ਸੁਧਾਰਿਆ। ਨਤੀਜਾ ਉਹ ਬੁਨਿਆਦ ਹੈ ਜਿਸ 'ਤੇ ਆਨਲਾਈਨ ਭਰੋਸਾ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਕਾਇਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਦਾ ਮੁੱਖ ਉਦੇਸ਼ ਸਧਾਰਣ ਹੈ ਪਰ ਹਕੀਕਤ ਵਿੱਚ ਪਹੁੰਚਣਾ ਔਖਾ: ਐਲਿਸ ਅਤੇ ਬੌਬ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਅੰਤ ਵਿੱਚ ਉਹ ਇਕੋ ਗੁਪਤ ਕੁੰਜੀ 'ਤੇ ਪਹੁੰਚਣ, ਭਾਵੇਂ ਕੋਈ ਨਜ਼ਰ ਰੱਖ ਰਿਹਾ ਹੋਵੇ। ਉਹ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਗੱਲ ਕਰ ਸਕਦੇ ਹਨ; ਉਹ ਸਿਰਫ ਇੰਝ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਹੋਰ ਕੋਈ ਅੰਤਿਮ ਗੁਪਤ ਨੂੰ ਜਾਣ ਲਏ।
ਕਲਪਨਾ ਕਰੋ ਐਲਿਸ ਅਤੇ ਬੌਬ ਇਕ ਖੁੱਲੇ Wi‑Fi 'ਤੇ ਹਨ। ਈਵ ਹਰ ਸੁਨੇਹੇ ਨੂੰ ਸੁਣ ਰਹੀ ਹੈ। ਐਲਿਸ ਅਤੇ ਬੌਬ ਸ਼ੁਰੂਆਤ ਵਿਖੇ ਪਾਸਵਰਡ ਨਹੀਂ ਸਾਂਝਾ ਕਰ ਸਕਦੇ—ਕਿਉਂਕਿ ਉਹਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਕਾਲ ਰਿਕਾਰਡ ਹੋ ਸਕਦੀ ਹੈ।
ਇਸ ਦੀ ਬਜਾਏ ਉਹ ਇਕ ਚਤੁਰ "ਮਿਕਸਿੰਗ" ਤਰੀਕਾ ਵਰਤਦੇ ਹਨ:
ਅਖੀਰ 'ਤੇ, ਐਲਿਸ ਅਤੇ ਬੌਬ ਇੱਕੋ ਅੰਤਿਮ ਰੰਗ 'ਤੇ ਪਹੁੰਚਦੇ ਹਨ, ਜੋ ਉਹਨਾਂ ਦੀ ਸਾਂਝੀ ਕੁੰਜੀ ਬਣ ਜਾਂਦੀ ਹੈ।
ਈਵ ਪਬਲਿਕ ਨਿਯਮ ਅਤੇ ਮਿਕਸ ਕੀਤੇ ਨਤੀਜੇ ਦੇਖਦੀ ਹੈ ਜੋ ਆਉਂਦੇ-ਜਾਂਦੇ ਹਨ। ਈਵ ਉਹਨਾਂ ਸੁਨੇਹਿਆਂ ਦੀ ਨਕਲ, ਸਟੋਰ ਅਤੇ ਰੀਪਲੇ ਕਰ ਸਕਦੀ ਹੈ।
ਜੋ ਕੁਝ ਈਵ ਅਸਲ ਵਿੱਚ ਕਰ ਨਹੀਂ ਸਕਦੀ (ਮਜ਼ਬੂਤ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਹਾਲਤ ਵਿੱਚ) ਉਹ ਹੈ ਨਿੱਜੀ ਅਮਲ ਨੂੰ ਉਲਟ ਕੇ ਬਾਹਰ ਲਿਆਉਣਾ। ਮੂਲ ਵਿਚਾਰ ਇਹ ਹੈ: ਟਰਾਂਸਫ਼ਰ ਆਸਾਨ ਹੈ, ਰੀਵਰਸ ਦਿਸ਼ਾ ਗਣਨਾਤਮਕ ਤੌਰ 'ਤੇ ਔਖੀ ਹੈ—ਇੱਕ ਪ੍ਰਯੋਗਤਮਕ ਇਕ-ਰਾਸ਼ੀ ਸਮੱਸਿਆ।
ਅੰਤਮ ਸਾਂਝੀ ਕੁੰਜੀ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੇ ਸੰਵਾਦ ਨੂੰ ਸਿੱਧਾ ਇੰਕ੍ਰਿਪਟ ਕਰਨ ਲਈ ਨਹੀ̆ ਵਰਤੀ ਜਾਂਦੀ। ਇਸਨੂੰ ਇੱਕ ਕੀ-ਡੇਰੀਵੇਸ਼ਨ ਕਦਮ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਤੇਜ਼ ਸੀਮੇਟ੍ਰਿਕ ਇੰਕ੍ਰਿਪਸ਼ਨ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ (ਜੋ ਵੱਡੇ ਡੇਟੇ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੀ ਹੈ)। ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਉਹ ਪੁਲ ਹੈ ਜੋ ਦੋਨਾਂ ਪੱਖਾਂ ਨੂੰ ਇਕੋ ਗੁਪਤ 'ਤੇ ਲਿਆਉਂਦਾ ਹੈ—ਬਿਨਾਂ ਉਸ ਗੁਪਤ ਨੂੰ ਨੈੱਟਵਰਕ 'ਤੇ ਭੇਜੇ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਇੱਕ ਬਹੁਤ ਖਾਸ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ ਹੈ: ਦੋ ਪੱਖ ਇਕ ਗੁਪਤ 'ਤੇ ਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕੋਈ ਨਜ਼ਰ ਰੱਖ ਰਿਹਾ ਹੋਵੇ। ਪਰ ਅਨੇਕ ਅਸਲ ਹਮਲੇ ਸਿਰਫ "ਕੋਈ ਸੁਣ ਰਿਹਾ ਹੈ" ਵਾਲੇ ਨਹੀਂ—ਉਹ "ਕੋਈ ਦਰਮਿਆਨ ਬੈਠਾ ਹੈ" ਵਾਲੇ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਮਨ-ਇਨ-ਦ-ਮਿਡਲ ਹਮਲਾ ਵਿੱਚ, ਹਮਲਾਵਰ ਤੁਹਾਡੇ ਅਤੇ ਸਰਵਰ ਦੇ ਵਿਚਕਾਰ ਸੁਨੇਹਿਆਂ ਨੂੰ ਰੀਲੇ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਚੁਪਕੇ ਤੌਰ 'ਤੇ ਬਦਲ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਪਹਚਾਨ ਜਾਂਚ ਦੇ ਕੁੰਜੀ-ਆਦਾਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਹਮਲਾਵਰ ਤੁਹਾਡੇ ਨਾਲ ਇੱਕ ਕੁੰਜੀ-ਆਦਾਨ ਅਤੇ ਅਸਲੀ ਸਰਵਰ ਨਾਲ ਇੱਕ ਹੋਰ ਕਰ ਸਕਦਾ ਹੈ। ਅੰਤ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਚੰਗੀ ਕੁੰਜੀ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦੇ ਹੋ—ਪਰ ਉਹ ਹਮਲਾਵਰ ਨਾਲ ਸਾਂਝੀ ਹੋ ਸਕਦੀ ਹੈ।
ਇਸ ਲਈ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨਾਲ ਗੱਲ ਕਰ ਰਹੇ ਹੋ। ਇਹ ਪੈਸਿਵ ਸੁਣਨ ਵਾਲਿਆਂ ਖਿਲਾਫ ਗੁਪਤਤਾ ਦਿੰਦਾ ਹੈ, ਪਰ ਪਹਚਾਣ ਦੀ ਗਰੰਟੀ ਨਹੀਂ।
ਇਸ ਸੰਦਰਭ ਵਿੱਚ, "ਭਰੋਸਾ" ਦਾ ਮਤਲਬ ਗੱਲਾ-ਬਾਤਕਾਰੀ ਵਿਸ਼ਵਾਸ ਤੋਂ ਵੱਧ ਦਰੜ ਹੈ: ਤੁਸੀਂ ਯਕੀਨਾਂਣ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਮੰਨਿਆ ਗਿਆ ਪੱਖ ਹੀ ਪਹੁੰਚੇ ਹੋ, ਨਾ ਕਿ ਕੋਈ ਨਕਲੀ ਵਿਅਕਤੀ।
ਪ੍ਰੋਟੋਕੋਲ ਕੁੰਜੀ-ਆਦਾਨ ਨੂੰ ਅਸਲ ਪਹਚਾਣ ਨਾਲ ਜੋੜਨ ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ ਵਰਤਦੇ ਹਨ। ਆਮ ਤਰੀਕੇ ਸ਼ਾਮਲ ਹਨ:
ਆਧੁਨਿਕ ਸੁਰੱਖਿਅਤ ਪ੍ਰਣਾਲੀਆਂ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ (ਤਾਜ਼ਾ ਸੈਸ਼ਨ ਕੁੰਜੀਆਂ ਬਣਾਉਣ ਲਈ) ਨੂੰ ਪ੍ਰਮਾਣੀਕਰਨ (ਦੂਜੇ ਪੱਖ ਦੀ ਪਹچਾਣ ਸਾਬਤ ਕਰਨ ਲਈ) ਨਾਲ ਜੋੜਦੀਆਂ ਹਨ। ਇਹ ਜੋੜ—TLS ਵਿੱਚ HTTPS ਅਤੇ ਕਈ VPNs ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ—ਹਮਲਾਵਰ ਨੂੰ ਤੁਹਾਡੇ ਅਤੇ ਮਾਂਗੇ ਗਏ ਸਰਵਿਸ ਦੇ ਵਿਚਕਾਰ ਚੁਪਚਾਪ ਸ਼ਾਮਿਲ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਸਾਈਟ ਨੂੰ HTTPS ਰਾਹੀਂ ਵੇਖਦੇ ਹੋ, ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਐਸੇ ਸਰਵਰ ਨਾਲ ਗੱਲ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਇਸਨੇ ਕਦੇ ਪਹਿਲਾਂ ਨਹੀਂ ਮਿਲਿਆ—ਤੇ ਇਹ ਸਾਰਾ ਟ੍ਰੈਫਿਕ ਕਿਸੇ ਐਸੇ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਨਿਗਰਾਨ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਫਿਰ ਵੀ ਸੁਰੱਖਿਅਤ ਕਿਵੇਂ ਹੋ ਸਕਦਾ ਹੈ? ਕਿਉਂਕਿ ਕਨੈਕਸ਼ਨ ਛੇਤੀ ਹੀ ਤਾਜ਼ਾ ਇੰਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀਆਂ ਸੈਟ ਕਰ ਲੈਂਦਾ ਹੈ—ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਭੇਜੇ।
ਉਚੀ ਪੱਧਰ 'ਤੇ, HTTPS ਇੰਝ ਕੰਮ ਕਰਦਾ ਹੈ:
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਮੋੜਦਾ ਹੈ: ਇਹ ਦੋਨਾਂ ਪੱਖਾਂ ਨੂੰ ਇਕੋ ਰਾਜ਼ 'ਤੇ ਲਿਆਉਂਦਾ ਹੈ ਬਿਨਾਂ ਉਸ ਰਾਜ਼ ਨੂੰ ਨੈੱਟਵਰਕ 'ਤੇ "ਸ਼ਿਪ" ਕੀਤੇ।
TLS ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ, ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਹੁੰਦਾ ਹੈ—ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਕੋਈ ਨਿੱਜੀ ਡੇਟਾ ਜਿਵੇਂ ਪਾਸਵਰਡ ਜਾਂ ਕ੍ਰੈਡਿਟ ਕਾਰਡ ਨੰਬਰ ਨਹੀਂ ਭੇਜਣੇ ਚਾਹੀਦੇ। ਹੈਂਡਸ਼ੇਕ ਮੁੱਕਣ ਤੋਂ ਬਾਅਦ ਹੀ ਬ੍ਰਾਊਜ਼ਰ HTTP ਬੇਨਤੀਆਂ ਨੂੰ ਇੰਕ੍ਰਿਪਟ ਕੀਤੇ ਚੈਨਲ ਦੇ ਅੰਦਰ ਭੇਜਦਾ ਹੈ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਤੁਹਾਨੂੰ ਰਹੱਸਦਾਰੀ ਦਿੰਦਾ ਹੈ, ਪਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਪਹਚਾਣ ਨਹੀਂ ਦਿੰਦਾ। ਇਹੀ ਕੰਮ ਸਰਟੀਫਿਕੇਟ ਕਰਦੇ ਹਨ। ਇੱਕ ਵੈੱਬਸਾਈਟ ਸਰਟੀਫਿਕੇਟ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ "ਇਹ public key example.com ਨਾਲ ਸਬੰਧਿਤ ਹੈ," ਜਿਸ ਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ Certificate Authority ਨੇ ਸਾਈਨ ਕੀਤਾ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਡੋਮੇਨ ਨਾਮ, ਮਿਆਦਾਂ ਅਤੇ ਸਿਗਨੇਚਰ ਚੇਨ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ; ਜੇ ਕੁਝ ਗੜਬੜ ਹੋਵੇ ਤਾਂ ਇਹ ਤੁਹਾਨੂੰ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ।
https:// ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਸੁਰੱਖਿਆ ਸੂਚਕ ਨੂੰ ਦੇਖੋ, ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲਓ।
ਇੱਕ ਗਲਤ ਫਹਿਮੀ: HTTPS ਤੁਹਾਨੂੰ ਗੁਪਤ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਇਹ ਤੁਹਾਡੇ ਭੇਜੇ-ਪ੍ਰਾਪਤ ਕੀਤੇ ਸਮੱਗਰੀ ਨੂੰ ਇੰਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਪਰ ਤੁਹਾਡਾ IP ਪਤਾ, ਕਨੈਕਸ਼ਨ ਕਰਨ ਦਾ факт ਅਤੇ ਅਕਸਰ ਡੋਮੇਨ ਵੀ ਨੈੱਟਵਰਕ ਅਤੇ ਇੰਟਰਮੀਡੀਏਰੀਆਂ ਨੂੰ ਦਿੱਖ ਸਕਦਾ ਹੈ।
ਫਾਰਵਰਡ ਸੀਕਰੇਸੀ (ਕਈ ਵਾਰੀ "perfect forward secrecy" ਵੀ ਕਹਿੰਦੇ ਹਨ) ਦਾ ਮਤਲਬ ਇਹ ਹੈ: ਜੇ ਕਿਸੇ ਨੇ ਭਵਿੱਖ ਵਿੱਚ ਕੋਈ ਲੰਬੇ ਸਮੇਂ ਦੀ ਕੁੰਜੀ ਚੋਰੀ ਕਰ ਲਈ, ਫਿਰ ਵੀ ਉਹ ਪੁਰਾਣੀਆਂ ਰਿਕਾਰਡ ਕੀਤੀਆਂ ਸੰਭਾਵਿਤ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰ ਸਕੇਗਾ।
ਇਹ ਇਸ ਲਈ ਮਤਲਬੀ ਹੈ ਕਿਉਂਕਿ ਹਮਲਾਵਰ ਅਕਸਰ ਅੱਜ ਇੰਕ੍ਰਿਪਟ ਕੀਤੀਆਂ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰ ਲੈਂਦੇ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਤੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਪ੍ਰਣਾਲੀ ਇੱਕ ਹੀ ਲੰਬੇ ਸਮੇਂ ਵਾਲੀ ਕੁੰਜੀ ਨੂੰ ਬਹੁਤ ਸਾਰਿਆਂ ਸੈਸ਼ਨਾਂ ਲਈ ਦੁਹਰਾਉਂਦੀ ਹੈ, ਤਾਂ ਇਕ ਲੀਕ ਸੌਂ ਨਾਲ ਪਿਛਲੇ ਮਹੀਨਿਆਂ ਜਾਂ ਸਾਲਾਂ ਦਾ ਡੇਟਾ ਖਤਰੇ ਵਿੱਚ ਪੈ ਸਕਦਾ ਹੈ।
ਦੁਹਰਾਈਆਂ ਕੁੰਜੀਆਂ ਇੱਕ single point of failure ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਜਿੰਨੀ ਲੰਬੀ ਕਿਸੇ ਕੁੰਜੀ ਦੀ ਉਮਰ ਹੋਵੇਗੀ, ਉਸਨੂੰ ਕਾਪੀ ਹੋਣ, ਲੌਗ ਹੋਣ, ਗਲਤ ਕਾਨਫਿਗਰ ਹੋਣ ਜਾਂ ਸਰਵਰੋਂ ਖੋਹਿਆ ਜਾਣ ਦਾ ਖ਼ਤਰਾ ਵਧਦਾ ਹੈ। ਭਾਵੇਂ ਇੰਕ੍ਰਿਪਸ਼ਨ ਮਜਬੂਤ ਹੋਵੇ, ਪਰ ਕਾਰੋਬਾਰੀ ਹਕੀਕਤ ਇਹ ਹੈ ਕਿ ਲੰਬੇ ਸਮੇਂ ਦੀਆਂ ਗੁਪਤਾਂ ਆਖ਼ਿਰਕਾਰ ਲੀਕ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ।
ਐਫੀਮੇਰਲ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ (ਆਧੁਨਿਕ TLS ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ECDHE) ਹਰ ਵਾਰੀ ਜੁੜਨ 'ਤੇ ਤਾਜ਼ਾ, ਸੈਸ਼ਨ-ਨਿਯਤ ਗੁਪਤ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਸਰਵਰ ਇਕ ਛੋਟੀ ਕੁੰਜੀ-ਆਦਾਨ ਕਰਦੇ ਹਨ, ਇੱਕ-ਵਾਰੀ ਵਾਲੀ ਸੈਸ਼ਨ ਕੁੰਜੀ ਨਿਕਲਦੇ ਹਨ ਅਤੇ ਫਿਰ ਅਸਥਾਈ ਨਿੱਜੀ ਮੁੱਲਾਂ ਨੂੰ ਮੁਲਤਵੀ ਕਰ ਦਿੰਦੇ ਹਨ।
ਇਸ ਲਈ, ਜੇ ਸਰਵਰ ਦਾ ਸਰਟੀਫਿਕੇਟ ਕੁੰਜੀ ਬਾਅਦ ਵਿੱਚ ਚੋਰੀ ਹੋ ਜਾਏ, ਤਾਂ ਹਮਲਾਵਰ ਕੋਲ ਪਿਛਲੇ ਸੈਸ਼ਨਾਂ ਦੀਆਂ ਕੁੰਜੀਆਂ ਨੂੰ ਬਨਾਉਣ ਲਈ ਲੋੜੀਂਦੇ ਅਨਹੈਡਿੰਗ ਗੁਣਕ ਨਹੀਂ ਹੋਉਂਦੇ।
ਫਾਰਵਰਡ ਸੀਕਰੇਸੀ ਨਾਲ ਬਚਾਅ:
ਇਹ ਨਹੀਂ ਬਚਾਉਂਦਾ:
ਜਿਨ੍ਹਾਂ ਕੰਫਿਗਰੇਸ਼ਨਾਂ ਨੇ ਫਾਰਵਰਡ ਸੀਕਰੇਸੀ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਹੈ ਉਹ ਨ.metadataਿਆ ਦੀ ਘੱਟ ਹੱਦ ਤੱਕ ਨੁਕਸਾਨ ਸੀਮਾ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ:
VPN (ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਨੈੱਟਵਰਕ) ਅਸਲ ਵਿੱਚ ਇਕ ਪ੍ਰਾਈਵੇਟ “ਟਿਊਬ” ਹੈ ਜੋ ਤੁਹਾਡੇ ਡਿਵਾਈਸ ਅਤੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ VPN ਸਰਵਰ ਦੇ ਵਿਚਕਾਰ ਉਸ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਬਣਾਈ ਜਾਂਦੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕਾਬੂ ਨਹੀਂ ਰੱਖਦੇ—ਜਿਵੇਂ ਪਬਲਿਕ Wi‑Fi, ਹੋਟਲ ਰਾਊਟਰ ਜਾਂ ISP ਕਨੈਕਸ਼ਨ। ਮਕਸਦ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੰਕ੍ਰਿਪਟ ਅਤੇ ਤਬਦੀਲੀ ਤੋਂ ਮੁਸ਼ਕਲ ਬਣਾਉਣਾ ਹੈ ਜਦੋਂ ਇਹ ਅਣ-ਭਰੋਸੇਯੋਗ ਹੱਪਾਂ ਤੋਂ ਲੰਘ ਰਿਹਾ ਹੋਵੇ।
ਜਦੋਂ ਤੁਸੀਂ VPN ਨਾਲ ਜੁੜਦੇ ਹੋ, ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਤੇ VPN ਸਰਵਰ ਪਹਿਲਾਂ ਇਸ ਸੈਸ਼ਨ ਲਈ ਤਾਜ਼ਾ ਇੰਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀਆਂ 'ਤੇ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ। ਇਹ ਸਹਿਮਤੀ Diffie-Hellman-ਸ਼ੈਲੀ ਇੰਟ੍ਹੰ ਦੇ ਨਾਲ ਜਾਂ elliptic-curve ਵੇਰੀਐਂਟ ਰਾਹੀਂ ਹੁੰਦੀ ਹੈ, ਜੋ ਕਿ ਸਾਂਝੀ ਰਾਜ਼ ਨੂੰ ਬਣਾਉਂਦੀ ਹੈ ਬਿਨਾਂ ਉਸਨੂੰ ਭੇਜੇ।
ਇੱਕ ਵਾਰੀ ਦੋਨਾਂ ਪੱਖਾਂ ਕੋਲ ਸਾਂਝੀ ਰਾਜ਼ ਹੋ ਜਾਵੇ, ਉਹ ਸੀਮੇਟ੍ਰਿਕ ਕੁੰਜੀਆਂ ਨਿਕਾਲ ਕੇ ਦੋਹਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਡੇਟਾ ਇੰਕ੍ਰਿਪਟ ਕਰਦੇ ਹਨ। ਉਹਨਾਂ ਤੋਂ ਬਾਅਦ VPN ਟਨਲ ਤੇਜ਼ ਸੀਮੇਟ੍ਰਿਕ ਇੰਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਇੰਟੀਗ੍ਰਿਟੀ ਚੈੱਕ ਬਣ ਕੇ ਕੰਮ ਕਰਦਾ ਹੈ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਤੁਹਾਨੂੰ ਰਹੱਸਦਾਰੀ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨਾਲ ਗੱਲ ਕਰ ਰਹੇ ਹੋ। VPNs ਆਮ ਤੌਰ 'ਤੇ ਅੰਤ-ਪੱਧੀ ਪ੍ਰਮਾਣੀਕਰਨ ਵੀ ਕਰਦੇ ਹਨ—ਸਰਟੀਫਿਕੇਟ, ਪਹਿਲਾਂ-ਸਾਂਝੀ ਕੀਜ਼ ਜਾਂ ਯੂਜ਼ਰ ਪ੍ਰਮਾਣਿਕਤਾ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਕਿਸੇ ਹਮਲਾਵਰ ਨਾਲ ਟਨਲ ਨਾ ਬਣਾਉ।
ਜ਼ਿਆਦਾਤਰ VPN ਬਰੀਚਾਂ ਮਨੁੱਖੀਆਂ ਅਤੇ ਕਾਨਫਿਗਰੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਸੰਬੰਧਤ ਹੁੰਦੀਆਂ ਹਨ, ਨਾ ਕਿ “ਇੰਕ੍ਰਿਪਸ਼ਨ ਟੁੱਟਣ” ਨਾਲ:
VPN ਉਸ ਸਮੇਂ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਅਣ-ਭਰੋਸੇਯੋਗ ਨੈੱਟਵਰਕ 'ਤੇ ਟਰੈਫਿਕ ਦੀ ਸੁਰੱਖਿਆ ਚਾਹੀਦੀ ਹੋਵੇ, ਨਿੱਜੀ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੋਵੇ, ਜਾਂ ਸਾਂਝੇ Wi‑Fi 'ਤੇ ਖੁਲਾਸਾ ਘਟਾਉਣਾ ਹੋਵੇ। ਇਹ ਤੁਹਾਨੂੰ ਖ਼ਤਰਨਾਕ ਵੈੱਬਸਾਈਟਾਂ, ਸੰਕਰਮਿਤ ਡਿਵਾਈਸਾਂ ਜਾਂ ਖ਼ਰਾਬ ਅਕਾਊਂਟ ਸੁਰੱਖਿਆ ਤੋਂ ਬਚਾਉਂਦਾ ਨਹੀਂ—ਅਤੇ ਇਹ ਵਿਸ਼ਵਾਸ VPN ਪ੍ਰੋਵਾਈਡਰ ਜਾਂ ਤੁਹਾਡੇ ਸੰਗਠਨ ਦੇ VPN ਗੇਟਵੇ 'ਤੇ ਸਥਾਪਤ ਕਰਦਾ ਹੈ।
ਆਧੁਨਿਕ ਸੁਰੱਖਿਅਤ ਕਨੈਕਸ਼ਨਾਂ ਇੱਕ ਆਸਾਨ ਨਮੂਨਾ ਪਾਲਣਦੀਆਂ ਹਨ: ਇੱਕ ਛੋਟਾ ਹੈਂਡਸ਼ੇਕ ਕਰਕੇ ਤਾਜ਼ਾ ਰਾਜ਼ਾਂ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ, ਫਿਰ ਬਾਕੀ ਸੈਸ਼ਨ ਲਈ ਤੇਜ਼ ਇੰਕ੍ਰਿਪਸ਼ਨ ਵਰਤੋ।
ਇਸ ਮਿਸ਼ਰਣ ਨੂੰ ਹਾਈਬ੍ਰਿਡ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਕਹਿੰਦੇ ਹਨ। ਇਹ ਲਾਜ਼ਮੀ ਹੈ ਕਿਉਂਕਿ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਲਈ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਗਣਿਤੀ ਥੋੜੀ ਮਹਿੰਗੀ ਹੁੰਦੀ ਹੈ, ਜਦਕਿ ਸੀਮੇਟ੍ਰਿਕ ਇੰਕ੍ਰਿਪਸ਼ਨ (AES ਜਾਂ ChaCha20 ਵਰਗੇ) ਹਰ ਯੰਤਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲਣ ਲਈ ਬਣਾਈ ਗਈ ਹੈ।
ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ, ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਸਰਵਰ ਪੈਰਾਮੀਟਰਾਂ 'ਤੇ ਸਹਿਮਤ ਹੋ ਕੇ ਸਰਵਰ ਨੂੰ ਪ੍ਰਮਾਣੀਕਰਤ ਕਰਦੇ ਹਨ ਅਤੇ ਸਾਂਝੀ ਸੈਸ਼ਨ ਕੁੰਜੀਆਂ ਨਿਕਾਲਦੇ ਹਨ। ਇਹ ਪੜਾਅ ਬਾਈਟਾਂ ਵਿੱਚ ਛੋਟਾ ਪਰ ਗਣਨਾਤਮਕ ਤੌਰ 'ਤੇ ਭਾਰੀ ਹੁੰਦਾ ਹੈ।
ਇਕ ਵਾਰੀ ਕੁੰਜੀਆਂ ਸੈਟ ਹੋ ਜਾਣ 'ਤੇ, ਕਨੈਕਸ਼ਨ "ਬਲਕ ਮੋਡ" ਵਿੱਚ ਚੱਲਦਾ ਹੈ: ਪੇਜ਼, ਈਮੇਜ, API ਜਵਾਬ ਅਤੇ ਅੱਪਲੋਡ ਆਦਿ ਸੀਮੇਟ੍ਰਿਕ ਇੰਕ੍ਰਿਪਸ਼ਨ ਨਾਲ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦੇ ਹਨ ਜੋ ਵੱਡੇ ਪੈਮਾਣੇ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ।
ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ, CPU ਅਤੇ ਬੈਟਰੀ ਦੀਆਂ ਸੀਮਾਵਾਂ ਕਾਰਨ ਹੈਂਡਸ਼ੇਕ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਨੈੱਟਵਰਕ ਅਟਕ-ਬਟਕ ਰਹੇ ਹੋਣ।
ਜਿਆਦਾ ਟ੍ਰੈਫਿਕ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਲਈ, ਹਜ਼ਾਰਾਂ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਪ੍ਰਤੀ ਸਕਿੰਟ ਹੈਂਡਸ਼ੇਕ ਦੀ ਕੀਮਤ ਵਧ ਸਕਦੀ ਹੈ।
ਦੋਹਰਾਈਆਂ ਹੈਂਡਸ਼ੇਕਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ, TLS session resumption ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ: ਜੇ ਤੁਸੀਂ ਜਲਦੀ ਮੁੜ ਕਨੈਕਟ ਹੋ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਸਰਵਰ ਪਿਛਲੇ ਸਟੇਟ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤ ਕੇ ਘੱਟ ਰਾਊਂਡ ਟ੍ਰਿਪ ਅਤੇ ਘੱਟ ਗਣਨਾ ਵਿੱਚ ਇਨਕ੍ਰਿਪਟੈਡ ਸੈਸ਼ਨ ਸਥਾਪਿਤ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਸਾਈਟਾਂ ਨੂੰ ਤੇਜ਼ ਮਹਿਸਸ ਕਰਵਾਉਂਦਾ ਹੈ ਬਿਨਾਂ ਤਾਜ਼ਾ ਸੈਸ਼ਨ ਦੀ ਮੂਲ ਸੁਰੱਖਿਆ ਨੂੰ ਕਮਜ਼ੋਰ ਕੀਤੇ।
ਜ਼ਿਆਦਾ ਕੜੀ ਸੁਰੱਖਿਆ ਸੈਟਿੰਗਜ਼ ਕੁਝ ਵਧੇਰੇ ਸਮੇਂ ਲੈ ਸਕਦੀਆਂ ਹਨ (ਮਜ਼ਬੂਤ ਪੈਰਾਮੀਟਰ, ਕਠੋਰ ਵੈਰੀਫਿਕੇਸ਼ਨ), ਜਦਕਿ ਜ਼ੋਰਦਾਰ ਪ੍ਰਦਰਸ਼ਨ ਵਿਕਲਪ ਗਲਤ ਵਰਤੋਂ 'ਤੇ ਖਤਰਾ ਵਧਾ ਸਕਦੇ ਹਨ। ਮੂਲ ਬਿੰਦੂ: ਹੈਂਡਸ਼ੇਕ ਛੋਟੀ ਸੀ ਹੈ—ਪਰ ਇਹੀ ਥਾਂ ਹੈ ਜਿਥੇ ਸੁਰੱਖਿਆ ਸਹੀ ਢੰਗ ਨਾਲ ਸਥਾਪਤ ਹੁੰਦੀ ਹੈ ਜਾਂ ਖੋਹ ਜਾਂਦੀ ਹੈ।
"ਜ਼ੀਰੋ-ਟ੍ਰਸਟ" ਸਿਧਾਂਤ ਸਧਾਰਣ ਹੈ: ਕਦੇ ਵੀ ਨੈੱਟਵਰਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਮਾਨ ਕੇ ਨਾ ਚੱਲੋ। ਹਰ ਕਨੈਕਸ਼ਨ ਨੂੰ ਅਜਿਹਾ ਮਾਨੋ ਜਿਵੇਂ ਕੋਈ ਦਿਖ ਸਕਦਾ, ਛੇਡੀ-ਛਾੜ ਕਰ ਸਕਦਾ ਜਾਂ ਸੇਵਾ ਦੀ ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ।
Hellman ਦਾ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਮਨੋਭਾਵ ਇਸ ਨਾਲ ਬਿਲਕੁਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। Diffie–Hellman ਨੇ ਨੈੱਟਵਰਕ ਨੂੰ "ਭਲੇ" ਮੰਨਣ ਦੀ ਲੋੜ ਦੇ ਬਿਨਾਂ ਗੁਪਤਤਾ ਸੰਭਵ ਬਣਾਈ। ਜ਼ੀਰੋ-ਟ੍ਰਸਟ ਇਹੀ ਧਾਰਨਾ ਲੈ ਕੇ ਹੋਰ ਕੰਟਰੋਲਾਂ—ਪਹਚਾਣ, ਐਕਸੈਸ ਅਤੇ ਤਾਪ-ਤਾਪ ਸੰਦਰਭਾਂ—ਤੇ ਲਗਾਉਂਦਾ ਹੈ।
ਆਧੁਨਿਕ ਪ੍ਰਣਾਲੀਆਂ ਬਹੁਤ ਸੇਵਾਵਾਂ ਤੋਂ ਬਣੀਆਂ ਹੁੰਦੀਆਂ ਹਨ—APIs, ਡੈਟਾਬੇਸ, 큐ਜ਼ ਅਤੇ ਅੰਦਰੂਨੀ ਟੂਲ। ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਦੋ ਐਂਡਪਾਇੰਟਾਂ ਨੂੰ ਚਲਾਉਣਯੋਗ ਤੌਰ 'ਤੇ ਤਾਜ਼ਾ ਇੰਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀਆਂ ਬਣਾ ਕੇ ਭਰੋਸਾ ਸਥਾਪਤ ਕਰਨ ਦਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਟਰੈਫਿਕ ਉਹਨਾਂ ਨੈੱਟਵਰਕਾਂ ਰਾਹੀਂ ਲੰਘੇ ਜੋ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਾਬੂ ਨਹੀਂ ਕਰਦੇ।
ਇਸੇ ਲਈ ਸੇਕਿਊਰ ਸਰਵਿਸ ਮੇਸ਼, ਅੰਦਰੂਨੀ TLS ਅਤੇ VPN ਟਨਲ ਐਕਟੀਵ ਮਿਸ਼ਨਾਂ ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਆਮ ਤੌਰ 'ਤੇ ਆਟੋਮੇਟਿਕ ਕੁੰਜੀ ਨੇਗੋਸ਼ੀਏਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ—ਲੰਬੇ ਸਮੇਂ ਦੀਆਂ ਸਾਂਝੀਆਂ ਗੁਪਤਾਂ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਵੰਡਣ ਦੇ ਬਦਲੇ।
ਇੰਕ੍ਰਿਪਸ਼ਨ ਸਿਰਫ ਸਮੱਗਰੀ ਨੂੰ ਛੁਪਾਉਂਦੀ ਹੈ; ਇਹ ਇਹ ਗੈਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨਾਲ ਗੱਲ ਕਰ ਰਹੇ ਹੋ। ਜ਼ੀਰੋ-ਟ੍ਰਸਟ ਮਿਊਚੁਅਲ ਪ੍ਰਮਾਣੀਕਰਨ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ:
ਅਮਲ ਵਿੱਚ, ਇਹ ਸਰਟੀਫਿਕੇਟ, ਸਾਈਨ ਕੀਤੇ ਟੋਕਨ, ਡਿਵਾਈਸ ਪਛਾਣਾਂ ਜਾਂ ਵਰਕਲੋਡ ਆਈਡੈਂਟਿਟੀ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ—ਅਤੇ ਫਿਰ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਉਹਨਾਂ ਤਸਦੀਕ ਕੀਤੀਆਂ ਪਛਾਣਾਂ ਨੂੰ ਵਰਤ ਕੇ ਸੈਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਕਰਦਾ ਹੈ।
ਜ਼ੀਰੋ-ਟ੍ਰਸਟ "ਸੈਟ-ਇਟ-ਅਤੇ-ਭੁੱਲ-ਜਾਓ" ਨੂੰ ਟਾਲਦਾ ਹੈ। ਇਸਦੀ ਬਜਾਏ, ਇਹ ਛੋਟੇ-ਉਮਰ ਵਾਲੇ ਕ੍ਰੈਡੈਂਸ਼ਲ ਅਤੇ ਅਕਸਰ ਕੁੰਜੀ ਘੁਮਾਉਣ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਜੇ ਕੁਝ ਲੀਕ ਹੋਵੇ ਤਾਂ ਨੁਕਸਾਨ ਸੀਮਿਤ ਰਹੇ। ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਇਸਨੂੰ ਸਸਤਾ ਬਣਾਉਂਦਾ ਹੈ: ਨਵੇਂ ਸੈਸ਼ਨ ਕੁੰਜੀਆਂ ਬਿਨਾਂ ਮਨੁੱਖੀ ਹਸਤਕੇਸ਼ ਦੇ ਨਿਰੰਤਰ ਬਣਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।
Hellman ਦਾ ਲੰਮਾ ਯੋਗਦਾਨ ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਨਹੀਂ—ਇਹ ਉਸ ਆਦਤ ਦਾ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਇਨ ਕਰੋ ਜਿਥੇ ਨੈੱਟਵਰਕ ਦੁਸ਼ਮਣ-ਭਰਿਆ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਰ ਵਾਰੀ ਭਰੋਸਾ ਸਾਬਤ ਕਰੋ, ਮੰਨ ਕੇ ਨਹੀਂ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ (Diffie–Hellman ਅਤੇ ਉਸਦੇ ਆਧੁਨਿਕ ਵੇਰੀਐਂਟਸ ਸਮੇਤ) ਖੁੱਲੇ ਨੈਟਵਰਕਾਂ 'ਤੇ ਨਿੱਜੀ ਸੰਚਾਰ ਲਈ ਬੁਨਿਆਦ ਹੈ—ਪਰ ਇਹ ਜਾਦੂਈ ਬੁਲਰ ਨਹੀਂ ਹੈ। ਬਹੁਤ ਸਾਰੀ ਸੁਰੱਖਿਆ ਗਲਤਫਹਿਮੀ ਇਸ ਗੱਲ ਤੋਂ ਆਉਂਦੀ ਹੈ ਕਿ "ਇਨਕ੍ਰਿਪਟਿਡ" ਦਾ ਅਰਥ ਹੈ "ਹਰ ਰੂਪ ਵਿੱਚ ਸੁਰੱਖਿਅਤ"। ਐਸਾ ਨਹੀਂ ਹੈ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਸੰਚਾਰ ਨੂੰ ਟਰਾਂਜਿਟ ਵਿੱਚ ਹੋਣ ਵਾਲੀ ਨਿਗਰਾਨੀ ਅਤੇ ਪੈਸਿਵ ਇੰਟਰਸੈਪਸ਼ਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਏਂਡਪਾਇੰਟਾਂ ਦੇ ਕੰਪ੍ਰੋਮਾਈਜ਼ ਤੋਂ ਬਚਾਉਂਦਾ ਨਹੀਂ।
ਜੇ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ ਮੈਲਵੇਅਰ ਹੈ, ਤਾਂ ਉਹ ਸੁਨੇਹਿਆਂ ਨੂੰ ਇੰਕ੍ਰਿਪਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਹੀ ਤਰ੍ਹਾਂ, ਜੇ ਹਮਲਾਵਰ ਨੇ ਸਰਵਰ ਨੂੰ ਕਾਬੂ ਕਰ ਲਿਆ, ਤਾਂ ਉਹ Diffie–Hellman ਨੂੰ ਟੋੜਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਉਹ ਸਿੱਧਾ ਸਰੋਤ ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ।
ਇੰਕ੍ਰਿਪਸ਼ਨ ਆਮਤੌਰ ਤੇ ਸਮੱਗਰੀ ਨੂੰ ਛੁਪਾਉਂਦੀ ਹੈ, ਸਾਰੇ ਸੰਦਰਭ ਨੂੰ ਨਹੀਂ। ਕਈ ਅਸਲ ਤੌਰ 'ਤੇ, ਕੁਝ ਮੈਟਾਡੇਟਾ ਅਜੇ ਵੀ ਲੀਕ ਹੋ ਸਕਦਾ ਹੈ:
ਇਹੀ ਕਰਕੇ ਪ੍ਰਾਈਵੇਸੀ ਟੂਲ ਇੱਕਥੇ ਲੇਅਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਇੱਕ ਹੀ ਫੀਚਰ 'ਤੇ ਨਿਰਭਰ।
HTTPS ਇਸ ਗੱਲ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਸਾਈਟ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਉਹੀ ਹੈ। ਇਹ ਸਿਰਫ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਕਨੈਕਸ਼ਨ ਕਿਸੇ ਸਰਵਰ ਨਾਲ ਇੰਕ੍ਰਿਪਟ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਸਰਟੀਫਿਕੇਟ ਰਾਹੀਂ ਪ੍ਰਮਾਣੀਕ੍ਰਿਤ।
ਫਿਸ਼ਰਿੰਗ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਹਮਲਾਵਰ:
ਇੰਕ੍ਰਿਪਸ਼ਨ ਜਾੜ-ਸੂਜ਼ੀ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ, ਧੋਖਾਧੜੀ ਤੋਂ ਨਹੀਂ। ਮਨੁੱਖ ਅਤੇ ਬ੍ਰਾਂਡ-ਭਰੋਸਾ ਅਭਿਆਸ ਅਜੇ ਵੀ ਇੱਕ ਵੱਡਾ ਹਮਲਾਵਰ ਸਤਹ ਹਨ।
ਚਲਾਉਣਕਾਰੀ ਨੁਕਸਾਨਾਂ ਨੇ ਅਕਸਰ ਸੁਰੱਖਿਆ ਨੂੰ ਖੋਖਲਾ ਕੀਤਾ:
ਆਧੁਨਿਕ ਕ੍ਰਿਪਟੋ ਮਜ਼ਬੂਤ ਹੈ, ਪਰ ਅਸਲ ਪ੍ਰਣਾਲੀਆਂ ਰਖ-ਰਖਾਅ, ਕੰਫਿਗਰੇਸ਼ਨ ਅਤੇ ਡਿਪਲੋਯਮੈਂਟ 'ਤੇ ਫਿਰ੍ਹੀਆਂ ਕਰਦੀਆਂ ਹਨ।
Hellman ਦੀਆਂ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਸੋਚਾਂ ਨੇ ਸਾਂਝੀ-ਗੁਪਤ ਸਮੱਸਿਆ ਹੱਲ ਕੀਤੀ, ਪਰ ਸੁਰੱਖਿਅਤ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਇੱਕ ਤੋਂ ਵੱਧ ਕੰਟਰੋਲ ਲੋੜੀਂਦੇ ਹਨ:
Hellman ਦਾ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਕਿਰਪਾ ਕਰਕੇ ਇੰਟਰਨੈੱਟ ਨੂੰ "ਸੁਰੱਖਿਅਤ" ਨਹੀਂ ਬਣਾਉਂਦਾ—ਪਰ ਇਹ ਇਸਨੂੰ ਇਕ ਐਸਾ ਢਾਂਚਾ ਦੇਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਨਿੱਜੀ ਗੱਲਬਾਤ ਕਰ ਸਕਦੇ ਹੋ ਭਾਵੇਂ ਤੁਸੀਂ ਰਾਸਤੇ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ। ਪ੍ਰਾਇਕਟੀਕਲ ਸਬਕ ਸਧਾਰਣ ਹੈ: ਨੈੱਟਵਰਕ ਨੂੰ ਵਿਪਰੀਤ ਮੰਨੋ, ਫਿਰ ਪਛਾਣਾਂ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਆਪਣੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖੋ।
ਜ਼ਿਆਦਾਤਰ ਸਾਈਟ ਕੰਪ੍ਰੋਮਾਈਜ਼ ਹੋਣ ਉਸ ਲਈ ਨਹੀ̆ ਹੁੰਦੇ ਕਿ "ਇੰਕ੍ਰਿਪਸ਼ਨ ਟੁੱਟ ਗਿਆ"—ਉਹ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇੰਕ੍ਰਿਪਸ਼ਨ ਗਲਤ ਤਰੀਕੇ ਨਾਲ কanhfig ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਾਂ ਜ਼ਿਆਦਾ ਪੁਰਾਣੀ ਰਹਿ ਜਾਂਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕਿੱਥੇ ਕਰੋ ਇਸਦੀ ਸਮਝ ਨਹੀਂ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਪੁਰਾਣੀਆਂ ਵਿਕਲਪਾਂ ਨੂੰ ਹਟਾਓ; ਬਹੁਤ ਹੀ ਪੁਰਾਣੇ ਕਲਾਇੰਟਾਂ ਨਾਲ ਅਨੁਕੂਲਤਾ ਆਮ ਤੌਰ 'ਤੇ ਖਤਰੇ ਵਥ ਮਨ੍ਹਦੀ ਹੈ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਇੱਕ ਸੰਕਲਪ ਹੈ; ਲਾਗੂਆਇਆਂ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਸੁਰੱਖਿਆ ਕਾਮਯਾਬ ਜਾਂ ਨਾਕਾਮ ਹੁੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਐਪ ਬਣਾ ਕੇ ਰਿਹਾਂ ਹੋ (ਉਦਾਹਰਣ ਲਈ Koder.ai ਵਰਤ ਕੇ React, Go + PostgreSQL, ਜਾਂ Flutter ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਬਣਾਉਣਾ), ਤਾਂ ਉਹੀ ਨਿਯਮ ਲਗੂ ਕਰੋ: ਮਿਆਰੀ TLS ਲਾਇਬ੍ਰੇਰੀਆਂ 'ਤੇ ਨਿਰਭਰ ਰੱਖੋ ਅਤੇ ਡਿਪਲੋਇਡ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸੈਟਿੰਗਜ਼ ਦੀ ਜਾਂਚ ਕਰੋ—ਕਸਟਮ ਡੋਮੇਨ, ਪ੍ਰੋਕਸੀ ਅਤੇ ਹੋਸਟਿੰਗ ਕੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੇਜ਼ ਸਮੇਂ 'ਤੇ ਸਰਟੀਫਿਕੇਟ ਅਤੇ TLS ਅਵਸਥਾ 'ਚ ਡ੍ਰਿਫਟ ਆਮ ਹੁੰਦਾ ਹੈ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਸੰਚਾਰ ਵਿੱਚ ਗੁਪਤਤਾ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਪਰ ਭਰੋਸਾ ਅਜੇ ਵੀ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨਾਲ ਗੱਲ ਕਰ ਰਹੇ ਹੋ।
ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ impersonation (ਨਕਲ) ਵਿਰੁੱਧ ਤੁਹਾਡੀ ਪਹਿਲੀ ਰੇਖਾ ਦੀ ਰੱਖਿਆ ਹਨ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਨੇ ਵਿਪਰੀਤ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਵਰਤੋਂਯੋਗ ਬਣਾਇਆ: ਤੁਸੀਂ ਗੁਪਤ ਤਰੀਕੇ ਨਾਲ ਗੱਲ ਕਰ ਸਕਦੇ ਹੋ ਭਾਵੇਂ ਤੁਸੀਂ ਰਸਤੇ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਉਪਰੋਕਤ ਚੈਕਲਿਸਟ ਉਹੀ ਮਨੋਭਾਵ ਦਿਖਾਉਂਦੀ—ਉਮੀਦ ਕਰੋ ਕਿ ਨੈੱਟਵਰਕ ਖਤਰੇ 'ਚ ਹੈ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਨੂੰ ਆਧੁਨਿਕ ਰੱਖੋ ਅਤੇ ਭਰੋਸਾ verified ਪਛਾਣ 'ਤੇ ਆਧਾਰਿਤ ਕਰੋ।
“ਵਿਪਰੀਤ ਨੈੱਟਵਰਕ” ਕਿਸੇ ਵੀ ਐਸੇ ਰਸਤੇ ਨੂੰ ਕਹਿੰਦਾ ਹੈ ਜਿੱਥੇ ਦਰਮਿਆਨੇ ਗਠਕ ਇਸਟਰਾffic ਨੂੰ ਦੇਖ, ਬਦਲ, ਰੋਕ ਜਾਂ ਰੀਰੂਟ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਕੋਈ ਦਿਲਵਰ ਵਿਅਕਤੀ ਹੋਵੇ—ਸਾਂਝਾ Wi‑Fi, ISP, ਪ੍ਰਾਕਸੀ ਜਾਂ ਕੰਪ੍ਰੋਮਾਈਜ਼ਡ ਰਾਊਟਰ ਵੀ ਕਾਫ਼ੀ ਹਨ।
ਵੈਕਤਿਗਤ ਨਤੀਜਾ: ਰਸਤੇ ਨੂੰ ਗੈਰ-ਭਰੋਸੇਯੋਗ ਮੰਨੋ ਅਤੇ ਇੰਕ੍ਰਿਪਸ਼ਨ + ਇਕਾਈਤਾ + ਪ੍ਰਮਾਣੀਕਰਨ 'ਤੇ ਨਿਰਭਰ ਰਹੋ, ਨਾ ਕਿ ਨੈੱਟਵਰਕ ਵਾਤਾਵਰਣ 'ਤੇ।
ਸਿਮੈਟ੍ਰਿਕ ਇੰਕ੍ਰਿਪਸ਼ਨ ਤੇਜ਼ ਹੈ, ਪਰ ਇਸ ਲਈ ਲੋੜ ਹੈ ਕਿ ਦੋਨਾਂ ਪੱਖਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਕੋ ਹੀ ਗੁਪਤ ਕੁੰਜੀ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਉਹ ਕੁੰਜੀ ਉੱਤੇ ਹੀ ਵੀਜਾਓਗੇ ਤਾਂ ਨਜ਼ਰ ਰੱਖਣ ਵਾਲਾ ਵੀ ਉਸਦੀ ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ।
ਇਸ ਗੋਲ ਚੱਕਰ—ਸੁਰੱਖਿਅਤ ਚੈਨਲ ਬਣਾਉਣ ਲਈ ਹੀ ਇਕ ਸੁਰੱਖਿਅਤ ਚੈਨਲ ਦੀ ਲੋੜ—ਨੂੰ ਕੁੰਜੀ ਵੰਡ ਸਮੱਸਿਆ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਜਿਸਨੂੰ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਨੇ ਤੋੜਿਆ।
ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਦੋ ਪੱਖਾਂ ਨੂੰ ਅਖੀਰਕਾਰ ਇਕੋ ਜਿਹੀ ਸਾਂਝੀ ਕੁੰਜੀ ਨਿਕਲਣ ਦਿੰਦਾ ਹੈ—ਬਿਨਾਂ ਆਪਣੀ ਨਿੱਜੀ ਕੁੰਜੀ ਨੂੰ ਨੈੱਟਵਰਕ ਉੱਤੇ ਭੇਜੇ। Diffie–Hellman-ਸ਼ੈਲੀ ਦੇ ਤਰੀਕਿਆਂ ਵਿੱਚ, ਹਰ ਪੱਖ:
ਨੂੰ ਮਿਲਾ ਕੇ ਅੰਤਿਮ ਸਾਂਝੀ ਕੁੰਜੀ ਬਣਾਉਂਦਾ ਹੈ। ਨਜ਼ਰ ਰੱਖਣ ਵਾਲਾ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਦੇਖ ਸਕਦਾ ਹੈ, ਪਰ ਮਜ਼ਬੂਤ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਅੰਟੀ-ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਅਖੀਰਲੇ ਕੁੰਜੀ ਨੂੰ ਤਿਆਰ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਇਸਨੇ ਸੁਰੱਖਿਅਤ ਸੈੱਟਅਪ ਨੂੰ “ਪਹਿਲਾਂ ਗੁਪਤ ਕੁੰਜੀ ਭੇਜੋ” ਤੋਂ ਬਦਲ ਕੇ “ਅਨਸੁਰੱਖਿਅਤ ਚੈਨਲ ਉੱਤੇ ਮੰਗ 'ਤੇ ਨਵੀਂ ਸਾਂਝੀ ਕੁੰਜੀ ਬਣਾਓ” ਬਣਾ ਦਿੱਤਾ।
ਇਹ ਬਦਲਾਅ ਬ੍ਰਾਊਜ਼ਰਾਂ ਅਤੇ ਵੈਬਸਰਵਰਾਂ ਵਾਂਗ ਅਜਾਣੇ ਡਿਵਾਈਸਾਂ ਲਈ ਤੁਰੰਤ ਅਤੇ ਪ੍ਰਾਥਮਿਕ ਤੌਰ 'ਤੇ ਇੰਕ੍ਰਿਪਟਿਡ ਸੈਸ਼ਨ ਬਣਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ—ਜੋ ਆਜ ਦੇ TLS ਵਰਗੇ ਪ੍ਰੋਟੋਕੋਲਾਂ ਦਾ ਫੁੰਡਾਮੈਂਟ ਹੈ।
ਨਹੀਂ। ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਮੁੱਖ ਤੌਰ 'ਤੇ ਰੁਕਵਾਲੀ ਨਜ਼ਰ ਰੱਖਣ ਵਾਲਿਆਂ ਤੋਂ ਸੰਗ੍ਰਹਿਤਤਾ ਦਿੰਦਾ ਹੈ। ਬਿਨਾ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ, ਤੁਸੀਂ ਫਿਰ ਵੀ ਕਿਸੇ ਠੱਗ ਨਾਲ ਕੁੰਜੀ-ਆਦਾਨ ਕਰ ਸਕਦੇ ਹੋ।
ਮੈਨ-ਇਨ-ਦ-ਮਿਡਲ ਹਮਲਿਆਂ ਤੋਂ ਬਚਣ ਲਈ, ਪ੍ਰੋਟੋਕੋਲ ਇੱਕ ਦੁਆਲੇ ਦੀ ਪਹਚਾਣ ਨੂੰ ਕੁੰਜੀ-ਆਦਾਨ ਨਾਲ ਬੰਨ੍ਹਦੇ ਹਨ—ਉਦਾਹਰਣ ਲਈ:
HTTPS ਵਿੱਚ, TLS ਹੈਂਡਸ਼ੇਕ ਅਕਸਰ ਇੰਝ ਚੱਲਦਾ ਹੈ:
ਹੁਣੇ,-server ਦਾ ਸਰਟੀਫਿਕੇਟ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿੱਤਾ-public key ਕਿਸ ਡੋਮੇਨ ਨਾਲ ਜੁੜਿਆ ਹੈ (ਉਦਾਹਰਣ: example.com), ਪਰ ਸਿਰਫ਼ ਇੰਕ੍ਰਿਪਸ਼ਨ ਹੀ ਪਛਾਣ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ।
ਫਾਰਵਰਡ ਸੀਕਰੇਸੀ ਦਾ ਮਤਲਬ ਹੈ: ਜੇ ਭਵੀਖ ਵਿੱਚ ਕੋਈ ਲੰਬੇ ਸਮੇਂ ਦੀ ਕੁੰਜੀ ਚੋਰੀ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਵੀ ਉਹ ਪਿਛਲੇ ਸੈਨਸ਼ਨਾਂ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰ ਸਕੇਗਾ।
ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਐਫੀਮੇਰਲ (ਅਸਥਾਈ) ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਨਾਲ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ (ਜਿਵੇਂ ECDHE) — ਹਰ ਸੈਸ਼ਨ ਲਈ ਤਾਜ਼ਾ, ਵਰਤਣ-ਬਾਦ ਫੇਂਕਣਯੋਗ ਪਦਾਰਥ ਬਣਾਏ ਜਾਂਦੇ ਹਨ।
VPN ਤੁਹਾਡੇ ਡਿਵਾਈਸ ਅਤੇ VPN ਸਰਵਰ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਗੁਪਤ ਟਨਲ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ VPN ਨਾਲ ਜੁੜਦੇ ਹੋ, ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਅਤੇ ਸਰਵਰ ਪਹਿਲਾਂ ਇਸ ਸੈਸ਼ਨ ਲਈ ਤਾਜ਼ਾ ਇੰਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀਆਂ ਤੇ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ—ਇਹੀ ਕੁੰਜੀ-ਆਦਾਨ-ਪਰਦਾਨ ਦਾ ਕਦਮ ਹੈ।
VPN ਨੈੱਟਵਰਕ 'ਤੇ ਗੁਪਤਤਾ ਜ਼ਰੂਰ ਬਢਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ:
ਅਮਲਕਾਰੀ ਨੁਕਤੇ:
