CA ਤੋਂ ਬਿਨਾਂ OpenVPN: peer-fingerprint ਸਾਥੀਆਂ ਨੂੰ ਕਿਵੇਂ ਪਰਖਦਾ ਹੈ
ਫਿੰਗਰਪ੍ਰਿੰਟ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਪਿੰਨ ਕਰਦਾ ਹੈ, ਸਾਂਝਾ ਭੇਤ ਨਹੀਂ। ਡਾਈਜੈਸਟ ਕੀ ਕਵਰ ਕਰਦਾ ਹੈ, ਹਰ ਪਾਸਾ ਆਪਣੀ ਮਨਜ਼ੂਰ ਸੂਚੀ ਕਿਵੇਂ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਨਵੀਨੀਕਰਨ ਦੀ ਕੀਮਤ ਕੀ ਹੈ, ਇਹ ਵੇਖੋ।
ਛੋਟੀ ਤੈਨਾਤੀ ਫਿੰਗਰਪ੍ਰਿੰਟ ਵੱਲ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀ ਅਜਿਹੀ ਢਾਂਚਾ ਲੱਗਦੀ ਹੈ ਜਿਸ ਨੂੰ ਚਲਾਉਣ ਲਈ ਕਿਸੇ ਕੋਲ ਸਮਾਂ ਨਹੀਂ। ਸੁਭਾਵਿਕ ਪ੍ਰਵਿਰਤੀ ਜਾਇਜ਼ ਹੈ, ਪਰ ਲੋਕ ਇਸ ਦੀ ਥਾਂ ਜੋ ਛੋਟਾ ਰਾਹ ਲੈਂਦੇ ਹਨ—ਇੱਕ ਡਾਟਾ-ਚੈਨਲ ਦਾ ਭੇਤ ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੇ ਕਾਪੀ ਕਰਨਾ—ਉਹ ਨਹੀਂ ਹੈ। peer-fingerprint ਸੈਟਅੱਪ TLS ਢਾਂਚੇ ਨੂੰ ਅਟੁੱਟ ਰੱਖਦਾ ਹੈ: ਹਰ ਪਾਸੇ ਕੋਲ ਅਜੇ ਵੀ ਆਪਣੀ ਨਿੱਜੀ ਚਾਬੀ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਹੈ, ਅਤੇ ਹਰ ਪਾਸਾ ਅਜੇ ਵੀ ਦੂਜੇ ਦੀ ਪਰਖ ਕਰਦਾ ਹੈ। ਬਦਲਦਾ ਇਹ ਹੈ ਕਿ ਪਰਖ ਕਿੱਥੇ ਲੰਗਰੀ ਹੋਈ ਹੈ: ਭਰੋਸੇਯੋਗ ਜਾਰੀਕਰਤਾ ਤੋਂ ਪਿੰਨ ਕੀਤੇ ਡਾਈਜੈਸਟਾਂ ਦੀ ਛੋਟੀ ਸੂਚੀ ਤੱਕ। ਡਾਈਜੈਸਟ ਨਾਮ ਨਹੀਂ ਬਲਕਿ ਪੂਰਾ ਸਰਟੀਫਿਕੇਟ ਕਵਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਨਵੀਨੀਕਰਨ ਉਹ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਸੱਚਮੁੱਚ ਸਮਾਂ ਲੈਂਦਾ ਹੈ।
ਫਿੰਗਰਪ੍ਰਿੰਟ ਅਸਲ ਵਿੱਚ ਕੀ ਵਚਨ ਦਿੰਦਾ ਹੈ
ਸਰਟੀਫਿਕੇਟ ਦਾ ਫਿੰਗਰਪ੍ਰਿੰਟ DER-ਇਨਕੋਡ ਕੀਤੇ ਪੂਰੇ ਸਰਟੀਫਿਕੇਟ ਦਾ ਡਾਈਜੈਸਟ ਹੈ, ਨਾ ਇਸ ਦੀ ਜਨਤਕ ਚਾਬੀ ਦਾ ਅਤੇ ਨਾ ਇਸ ਦੇ ਵਿਸ਼ਾ-ਨਾਮ ਦਾ। ਇਸ ਲਈ ਇੱਕੋ ਨਾਮ ਅਤੇ ਇੱਕੋ ਚਾਬੀ ਪਰ ਵੱਖਰੀਆਂ ਵੈਧਤਾ ਤਾਰੀਖਾਂ ਵਾਲੇ ਦੋ ਸਰਟੀਫਿਕੇਟਾਂ ਦੇ ਫਿੰਗਰਪ੍ਰਿੰਟ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਇਹੀ ਪਿੰਨਿੰਗ ਨੂੰ ਸਹੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਨਵੀਨੀਕਰਨ ਨੂੰ ਰੁਕਾਵਟ ਬਣਾਉਂਦਾ ਹੈ। ਪਿੰਨਿੰਗ ਦਾ ਅਰਥ ਆਮ ਤੌਰ ਤੇ ਚਾਬੀ ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਵਸਤੂ ਨੂੰ ਉਸ ਦੀ ਜ਼ਿੰਦਗੀ ਦੇ ਇੱਕ ਪਲ ਵਿੱਚ ਨਾਮ ਦਿੰਦਾ ਹੈ। ਕੋਈ ਵੀ ਡਾਈਜੈਸਟ ਜਾਣ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਜਾਣਨਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256ਮੇਲ ਖਾਂਦੀ ਨਿੱਜੀ ਚਾਬੀ ਦਾ ਮਾਲਕ ਹੋਣਾ ਹੀ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਾਥੀ ਕੋਲ ਉਹ ਸਰਟੀਫਿਕੇਟ ਹੈ, ਅਤੇ ਡਾਈਜੈਸਟ ਉਹ ਢੰਗ ਹੈ ਜਿਸ ਨਾਲ ਦੂਜਾ ਪਾਸਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਉਸ ਨੇ ਉਹ ਸਰਟੀਫਿਕੇਟ ਅਸਲ ਵਿੱਚ ਆਸ ਕੀਤਾ ਸੀ ਜਾਂ ਨਹੀਂ। ਇਹ ਵੱਖਰਾਉ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਇਹ ਡਿਜ਼ਾਈਨ ਪੁਰਾਣੀ ਸਾਂਝੇ-ਭੇਤ ਵਾਲੀ ਵਿਵਸਥਾ ਨਹੀਂ ਹੈ: ਸਾਂਝੀ ਚਾਬੀ ਉਸ ਹਰ ਵਿਅਕਤੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ ਜੋ ਉਹੀ ਬਾਈਟ ਜਾਣਦਾ ਹੈ, ਜਦ ਕਿ ਪਿੰਨਿੰਗ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ। ਵੱਖਰੇ ਯੰਤਰ ਨੂੰ ਉਸੇ ਭੇਤ ਦੀ ਨਕਲ ਨਹੀਂ ਬਲਕਿ ਆਪਣੀ ਐਂਟਰੀ ਮਿਲਦੀ ਹੈ, ਜੋ ਫਾਈਲਾਂ ਵਿੱਚ ਛੋਟਾ ਫਰਕ ਅਤੇ ਨੁਕਸਾਨ ਦੇ ਘੇਰੇ ਵਿੱਚ ਵੱਡਾ ਫਰਕ ਹੈ।
ਨਕਸ਼ਾ ਪਾਰਸਪਰਿਕ ਹੈ, ਸਮਮਿਤ ਨਹੀਂ
ਹਰ ਅੰਤ ਬਿੰਦੂ ਨੂੰ ਦੋ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਆਪਣੀ ਨਿੱਜੀ ਚਾਬੀ ਸਰਟੀਫਿਕੇਟ ਨਾਲ, ਅਤੇ ਇਹ ਬਿਆਨ ਕਿ ਕਿਹੜੇ ਸਾਥੀ ਸਰਟੀਫਿਕੇਟ ਸਵੀਕਾਰ ਕਰੇਗਾ। ਕਲਾਇੰਟ ਤੇ ਉਹ ਬਿਆਨ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਦਾ ਡਾਈਜੈਸਟ ਹੈ; ਸਰਵਰ ਤੇ ਉਹ ਰਜਿਸਟਰਡ ਕਲਾਇੰਟ ਡਾਈਜੈਸਟਾਂ ਦੀ ਸੂਚੀ ਹੈ। Community 2.6 ਲਈ ਛੋਟੀ ਸੈਟਅੱਪ ਦੀ ਸਰਕਾਰੀ ਉਦਾਹਰਨ peer-fingerprint ਨਾਲ ਬਣਤਰ ਦਿਖਾਉਂਦੀ ਹੈ, ਅਤੇ ਅਸਲ ਤੈਨਾਤੀ ਲਈ ਇਹ ਭਰੋਸਾ ਮਾਡਲ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਪੜ੍ਹਨਾ ਯੋਗ ਹੈ। ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਇੱਕ ਉਲਟੀ ਸੂਚੀ ਨਹੀਂ ਹਨ, ਅਤੇ ਉਹ ਇੱਕੋ ਪਲ ਵਿੱਚ ਫੇਲ ਨਹੀਂ ਹੁੰਦੀਆਂ।
| Verification direction | What is pinned | What never leaves that endpoint | How a wrong pin shows up |
|---|---|---|---|
| Client checks the server | One digest, for the server certificate | The server private key | The client aborts during the TLS handshake |
| Server checks the client | A digest per enrolled client | Each client private key | The server rejects the peer before a tunnel exists |
ਯੰਤਰ ਜੋੜਨਾ ਸਰਵਰ ਤੇ ਮਨਜ਼ੂਰ ਸੂਚੀ ਸੋਧਦਾ ਹੈ, ਮੌਜੂਦਾ ਕਲਾਇੰਟ ਦੀ ਨਿੱਜੀ ਸਮੱਗਰੀ ਕਾਪੀ ਕੀਤੇ ਬਿਨਾਂ ਅਤੇ ਸਰਵਰ ਚਾਬੀ ਨੂੰ ਕਿਤੇ ਨਾ ਹਿਲਾਏ ਬਿਨਾਂ। ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਵੀ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ, ਜੋ ਨਿਦਾਨ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹੈ: ਜਿਹੜਾ ਪਾਸਾ ਹੈਂਡਸ਼ੇਕ ਬੰਦ ਕਰਦਾ ਹੈ, ਉਹੀ ਪਾਸਾ ਹੈ ਜਿਸ ਦੀ ਆਸ ਪੂਰੀ ਨਹੀਂ ਹੋਈ। ਜੇ ਕਲਾਇੰਟ ਸਰਵਰ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ, ਤਾਂ ਡਾਈਜੈਸਟ ਪੇਸ਼ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਜੇ ਸਰਵਰ ਕਲਾਇੰਟ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸ ਕਲਾਇੰਟ ਦਾ ਡਾਈਜੈਸਟ ਸੂਚੀ ਵਿੱਚ ਨਹੀਂ, ਜਾਂ ਕਲਾਇੰਟ ਰਜਿਸਟਰਡ ਤੋਂ ਵੱਖਰਾ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕਰ ਰਿਹਾ ਹੈ।
ਰਜਿਸਟ੍ਰੇਸ਼ਨ: ਨਵਾਂ ਯੰਤਰ ਕਿਵੇਂ ਜੁੜਦਾ ਹੈ
ਨਵੇਂ ਯੰਤਰ ਦੀ ਚਾਬੀ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਉੱਥੇ ਹੀ ਬਣਾਓ ਜਿੱਥੇ ਨਿੱਜੀ ਚਾਬੀ ਰਹੇਗੀ, ਫਿਰ ਸਿਰਫ਼ ਜਨਤਕ ਵਸਤੂ ਨੂੰ ਉਸ ਪਾਸੇ ਲੈ ਜਾਓ ਜਿਸ ਨੂੰ ਇਸ ਨੂੰ ਪਿੰਨ ਕਰਨਾ ਹੈ। ਆਸ ਕੀਤਾ ਡਾਈਜੈਸਟ ਉਸ ਚੈਨਲ ਰਾਹੀਂ ਭੇਜੋ ਜਿਸ ਤੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਭਰੋਸਾ ਕਰਦੇ ਹੋ, ਅਤੇ ਜਾਣੇ-ਪਛਾਣੇ ਲੱਗਦੇ ਨਾਮ ਦੀ ਥਾਂ ਪੂਰੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਹੀ ਉਸੇ ਅਣ-ਪਰਖੀ ਡਾਊਨਲੋਡ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਡਾਈਜੈਸਟ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਦੋਵੇਂ ਫਾਈਲਾਂ ਆਪਸ ਵਿੱਚ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ। ਇਹ ਸਥਿਰਤਾ ਦੀ ਜਾਂਚ ਹੈ, ਪਛਾਣ ਦੀ ਨਹੀਂ, ਅਤੇ ਇਹ ਇਸ ਡਿਜ਼ਾਈਨ ਦੇ ਕਮਜ਼ੋਰ ਹੋਣ ਦਾ ਸਭ ਤੋਂ ਸ਼ਾਂਤ ਰਾਹ ਹੈ।
ਸਰਵਰ ਤੇ, ਡਾਈਜੈਸਟ ਜੋੜਨਾ ਇੱਕ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ ਹੈ ਜੋ ਆਮ ਮੈਨੇਜਰ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਹੁੰਦਾ ਹੈ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਵਾਂ ਯੰਤਰ ਜੁੜਦਾ ਹੈ ਅਤੇ ਜਿਸ ਯੰਤਰ ਦਾ ਡਾਈਜੈਸਟ ਹਟਾਇਆ ਗਿਆ ਹੈ ਉਹ ਹੁਣ ਨਹੀਂ ਜੁੜਦਾ। ਸਿਰਫ਼ ਸਕਾਰਾਤਮਕ ਕੇਸ ਕਵਰ ਕਰਨ ਵਾਲਾ ਟੈਸਟ ਮਨਜ਼ੂਰ ਸੂਚੀ ਨੂੰ ਅਣ-ਪਰਖਿਆ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਤੁਸੀਂ ਠੀਕ ਉਸੇ ਹਾਲਤ ਵਿੱਚ ਹੋਵੋਗੇ।
ਨਵੀਨੀਕਰਨ ਮਹਿੰਗਾ ਪਲ ਹੈ
ਹਰ ਸਰਟੀਫਿਕੇਟ ਦੀ ਮਿਆਦ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਚਾਬੀ ਅਤੇ ਨਾਮ ਇੱਕੋ ਰਹਿਣ ਤੇ ਵੀ ਨਵੇਂ ਸਰਟੀਫਿਕੇਟ ਦਾ ਨਵਾਂ ਡਾਈਜੈਸਟ ਹੁੰਦਾ ਹੈ। ਜਾਰੀਕਰਤਾ ਹੇਠ ਨਵੀਨੀਕਰਨ ਉਸ ਜਾਰੀਕਰਤਾ ਤੇ ਭਰੋਸਾ ਕਰਨ ਵਾਲੇ ਸਾਥੀਆਂ ਲਈ ਪਾਰਦਰਸ਼ੀ ਹੈ; ਪਿੰਨਿੰਗ ਹੇਠ ਇਹ ਸਰਟੀਫਿਕੇਟ ਪਿੰਨ ਕਰਨ ਵਾਲੇ ਹਰ ਸਾਥੀ ਲਈ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਦੀ ਘਟਨਾ ਹੈ।
ਮਿਆਦ ਖ਼ਤਮ ਹੋਣ ਦੀ ਤਾਰੀਖ ਤੋਂ ਬਾਅਦ ਨਹੀਂ, ਪਹਿਲਾਂ ਕ੍ਰਮ ਦੀ ਯੋਜਨਾ ਬਣਾਓ। ਨਵਾਂ ਡਾਈਜੈਸਟ ਉਹਨਾਂ ਧਿਰਾਂ ਨੂੰ ਵੰਡੋ ਜੋ ਇਸ ਦੀ ਪਰਖ ਕਰਦੇ ਹਨ, ਬਦਲਾਅ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਅੰਤ ਬਿੰਦੂ ਤੇ ਸਰਟੀਫਿਕੇਟ ਬਦਲੋ। ਇਹ ਕ੍ਰਮ ਕੋਈ ਅਜਿਹੀ ਖਿੜਕੀ ਨਹੀਂ ਛੱਡਦਾ ਜਿੱਥੇ ਦੋਵੇਂ ਪਾਸੇ ਇਸ ਗੱਲ ਤੇ ਅਸਹਿਮਤ ਹੋਣ ਕਿ ਕਿਹੜਾ ਸਰਟੀਫਿਕੇਟ ਚਾਲੂ ਹੈ। ਸੂਚੀ ਨੂੰ ਵੀ ਸਮੀਖਿਆ ਹੇਠ ਰੱਖੋ, ਕਿਉਂਕਿ ਪਿੰਨ ਕੀਤੀ ਸੂਚੀ ਮਹੀਨਿਆਂ ਪਹਿਲਾਂ ਹਟਾਏ ਯੰਤਰਾਂ ਦੀਆਂ ਐਂਟਰੀਆਂ ਇਕੱਠੀਆਂ ਕਰਦੀ ਹੈ। ਹਰ ਪੁਰਾਣੀ ਐਂਟਰੀ ਅਜਿਹੀ ਪਛਾਣ ਹੈ ਜੋ ਉਸ ਦੀ ਚਾਬੀ ਬਚਣ ਤੇ ਅਜੇ ਵੀ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਹਟਾਉਣਾ ਸਫ਼ਾਈ ਨਹੀਂ ਬਲਕਿ ਸੁਰੱਖਿਆ ਕਦਮ ਹੈ।
ਭਰੋਸਾ ਨਕਸ਼ਾ ਕੀ ਤੈਅ ਨਹੀਂ ਕਰਦਾ
ਪ੍ਰਮਾਣਿਕਤਾ ਇੱਕ ਪਰਤ ਹੈ, ਅਤੇ ਪਿੰਨ ਕੀਤਾ ਨਕਸ਼ਾ ਪਤਾ-ਪੂਲ, ਧੱਕੇ ਗਏ ਰੂਟ, ਰਾਹ ਦੇ MTU ਜਾਂ ਫਾਇਰਵਾਲ ਨੀਤੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਇਹ ਵੱਖਰੀ ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਵੱਖਰੇ ਫੇਲ ਹੋਣ ਦੇ ਢੰਗਾਂ ਨਾਲ ਰਹਿੰਦੇ ਹਨ। ਜੋ ਟਨਲ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ ਪਰ ਕੋਈ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਲੰਘਾਉਂਦਾ, ਉਹ ਕਦੇ ਨਾ ਉੱਠਣ ਵਾਲੇ ਟਨਲ ਤੋਂ ਵੱਖਰੀ ਜਾਂਚ ਹੈ।
ਨਕਸ਼ਾ ਵੀ ਬੇਅੰਤ ਨਹੀਂ ਵਧਦਾ, ਅਤੇ ਵੱਡੀਆਂ ਤੈਨਾਤੀਆਂ ਜਾਰੀਕਰਤਾ-ਅਧਾਰਿਤ PKI ਤੇ ਆ ਕੇ ਰੁਕਦੀਆਂ ਹਨ। ਇਹ ਤਰਜੀਹ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦੀ ਨਹੀਂ ਬਲਕਿ ਕਾਰਜਸੰਚਾਲਨ ਦੀ ਹੈ, ਕਿਉਂਕਿ ਬੇੜਾ ਵਧਣ ਨਾਲ ਹਰ ਸਾਥੀ ਤੇ ਸੂਚੀ ਸੋਧਣ ਦੀ ਥਾਂ ਇੱਕ ਅਥਾਰਟੀ ਰਾਹੀਂ ਪਛਾਣਾਂ ਜੋੜਨਾ ਅਤੇ ਹਟਾਉਣਾ ਸਸਤਾ ਹੈ। ਜਿੱਥੇ ਕਲਾਇੰਟ ਲਾਗੂਕਰਨ ਇਸ ਵਿਕਲਪ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ, ਉੱਥੇ ਜਵਾਬ ਉਹ ਅਨੁਕੂਲ ਭਰੋਸਾ ਮਾਡਲ ਹੈ ਜੋ ਉਹ ਕਲਾਇੰਟ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਜਾਂ ਸਮਰਥਿਤ ਬਦਲ ਹੈ। ਪਰਖ ਦੀ ਚੇਤਾਵਨੀ ਦਬਾਉਣਾ ਉਹ ਸਮਰਥਨ ਨਹੀਂ ਜੋੜਦਾ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਦਾ ਸਾਰਾ ਮੁੱਲ ਇਹ ਹੈ ਕਿ ਪਰਖ ਅਜੇ ਵੀ ਹੁੰਦੀ ਹੈ।