AES-256 VPN ಎನ್‌ಕ್ರಿಪ್ಷನ್ ಸೂಟ್ ಅನ್ನು ಏಕೆ ವಿವರಿಸುವುದಿಲ್ಲ
ಒಂದು ಸೂಟ್ ನಾಲ್ಕು ಪಾತ್ರಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ: ಬೃಹತ್ ಎನ್‌ಕ್ರಿಪ್ಷನ್, ಸಮಗ್ರತೆ, ಕೀ ಸ್ಥಾಪನೆ ಮತ್ತು ಸಹವರ್ತಿ ದೃಢೀಕರಣ. ಸೈಫರ್ ಹೆಸರು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ, ಒಂದು ಪದರದಲ್ಲಿ ಆವರಿಸುತ್ತದೆ.
VPN ಯಾವ ಎನ್‌ಕ್ರಿಪ್ಷನ್ ಬಳಸುತ್ತದೆ ಎಂದು ಕೇಳಿದರೆ ಉತ್ತರ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಪದದಲ್ಲಿ ಬರುತ್ತದೆ: AES-256, ಅಥವಾ ChaCha20, ಅಥವಾ ಬಹುಶಃ WireGuard. ಆ ಉತ್ತರವು ಒಂದು ಪದರದ ಒಂದು ಘಟಕವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಆದರೆ ಸಂಪರ್ಕವನ್ನು ನಿಜವಾಗಿ ರಕ್ಷಿಸುವುದು ನಾಲ್ಕು ವಿಭಿನ್ನ ಪಾತ್ರಗಳನ್ನು ಪೂರೈಸುವ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಗುಂಪು. ಘಟಕವನ್ನು ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಗೊಂದಲಿಸುವುದು ಈ ಸಂಭಾಷಣೆಗಳಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು, ಮತ್ತು ಅದು ಬಗೆಹರಿಸಲಾಗದ ಹೋಲಿಕೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಒಂದು ಸಂಪರ್ಕದೊಳಗೆ ನಾಲ್ಕು ಕೆಲಸಗಳು
ಬೃಹತ್ ಎನ್‌ಕ್ರಿಪ್ಷನ್ ಡೇಟಾ ಚಾನೆಲ್‌ಗಾಗಿ ಸ್ಪಷ್ಟ ಪಠ್ಯವನ್ನು ಸೈಫರ್ ಪಠ್ಯವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಕೀಯನ್ನು ಕಳುಹಿಸುವ ಬದಲು ಪಡೆಯಲಾಗುತ್ತದೆ. ಸಮಗ್ರತೆ ರಕ್ಷಣೆ ಬದಲಾವಣೆಯನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ, ಇದು ಪ್ರತ್ಯೇಕ ಕೆಲಸ, ಒಂದೇ ನಿರ್ಮಾಣ ಎರಡನ್ನೂ ಮಾಡಿದರೂ. ಕೀ ಸ್ಥಾಪನೆ ಹಂಚಿಕೆಯ ಸಂಚಾರ ಸಾಮಗ್ರಿಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಮತ್ತು ಸಹವರ್ತಿ ದೃಢೀಕರಣ ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿ ಯಾರಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಒಂದು ಇಲ್ಲದಿದ್ದರೆ ಸಂಪರ್ಕ ಸುರಕ್ಷಿತವಲ್ಲ, ಉಳಿದ ಭಾಗ ಎಷ್ಟೇ ಬಲವಾಗಿದ್ದರೂ.
ಕೆಲವು ವಿನ್ಯಾಸಗಳು ಎರಡು ಪಾತ್ರಗಳನ್ನು ಒಂದಾಗಿ ಸೇರಿಸುತ್ತವೆ. AES-GCM ಮತ್ತು ChaCha20-Poly1305 ದೃಢೀಕೃತ ಎನ್‌ಕ್ರಿಪ್ಷನ್ ನಿರ್ಮಾಣಗಳು, ಆದ್ದರಿಂದ ಗೋಪ್ಯತೆ ಮತ್ತು ಸಮಗ್ರತೆ ಒಟ್ಟಿಗೆ ಬರುತ್ತವೆ; AES-CBC ಹಾಗಲ್ಲ, ಅದಕ್ಕೆ ತನ್ನದೇ ಕೀಯನ್ನು ಹೊಂದಿರುವ ಪ್ರತ್ಯೇಕ ಸಂದೇಶ ದೃಢೀಕರಣ ಕೋಡ್ ಬೇಕು. ಆದ್ದರಿಂದ ಪ್ರಸ್ತಾವವನ್ನು ಸ್ವತಂತ್ರ ಸಂಖ್ಯೆಗಳ ಚೀಲವಾಗಿ ಓದುವುದು ಜೋಡಿಗಳಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದವುಗಳನ್ನು ತಪ್ಪಾಗಿ ಓದುತ್ತದೆ.
ಪಾತ್ರಗಳು ವಿವಿಧ ಪದರಗಳಲ್ಲಿಯೂ ಇರುತ್ತವೆ, ಆದ್ದರಿಂದ ಒಂದೇ ಪದ ಎರಡು ಉತ್ಪನ್ನಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಅರ್ಥವನ್ನು ನೀಡಬಹುದು. ESP ಒಳಗಿನ ಬ್ಲಾಕ್ ಸೈಫರ್ ಮತ್ತು TLS ಒಳಗಿನ ಬ್ಲಾಕ್ ಸೈಫರ್ ವಿಭಿನ್ನ ಅಗತ್ಯತೆಗಳಿರುವ ವಿಭಿನ್ನ ಮಾತುಕತೆಗಳಲ್ಲಿ ಒಂದೇ ಮೂಲ ಅಂಶ. ಆದ್ದರಿಂದ ಮೂಲ ಅಂಶವನ್ನು ಅದರ ಕ್ರಮ ಮತ್ತು ಪದರವಿಲ್ಲದೆ ಉಲ್ಲೇಖಿಸುವುದು ಏನನ್ನೂ ಉಲ್ಲೇಖಿಸದಿರುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿರಬಹುದು.
ಸೈಫರ್ ಹೆಸರು ಬಹುತೇಕ ಏನನ್ನೂ ಏಕೆ ಹೇಳುವುದಿಲ್ಲ
AES-256 ಪದಗುಚ್ಛವನ್ನು ಒಂದು ಕ್ಷಣ ಗಂಭೀರವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಿ: ಅದು ಬ್ಲಾಕ್ ಸೈಫರ್ ಮತ್ತು ಕೀ ಗಾತ್ರವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಕಾರ್ಯ ವಿಧಾನ, ಸಮಗ್ರತೆ ನೀಡಲಾಗಿದೆಯೇ, ಕೀಗಳನ್ನು ಹೇಗೆ ಸ್ಥಾಪಿಸಲಾಯಿತು ಅಥವಾ ಸಹವರ್ತಿಯನ್ನು ಹೇಗೆ ದೃಢೀಕರಿಸಲಾಯಿತು ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಎರಡು ಉತ್ಪನ್ನಗಳು ಎರಡೂ AES-256 ಜಾಹೀರಾತು ಮಾಡಬಹುದು ಮತ್ತು ಉಳಿದ ಎಲ್ಲದರಲ್ಲೂ ಭಿನ್ನವಾಗಿರಬಹುದು, ಅದರಲ್ಲಿ ಒಂದು ದೃಢೀಕರಿಸದ ಕ್ರಮದೊಂದಿಗೆ ಮತ್ತು ಇನ್ನೊಂದು ಆಧುನಿಕ ಕೀ ವಿನಿಮಯದೊಂದಿಗೆ AEAD ಕ್ರಮವನ್ನು ಬಳಸುತ್ತದೆ.
TLS 1.3 ಈ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಮಾನದಂಡಕ್ಕೆ ತಂದಿತು, ಇದು ಹಳೆಯ ಪದಕೋಶವನ್ನು ಕಲಿತವರಿಗೆ ಉಪಯುಕ್ತ ತಿದ್ದುಪಡಿ. ಅದರ ಸೈಫರ್ ಸೂಟ್‌ಗಳು AEAD ಮತ್ತು hash ಅನ್ನು ಮಾತ್ರ ಹೆಸರಿಸುತ್ತವೆ, ಆದರೆ ಕೀ ವಿನಿಮಯ ಗುಂಪುಗಳು ಮತ್ತು ಸಹಿ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಪ್ರತ್ಯೇಕ ನಿಯತಾಂಕಗಳಾಗಿ ಮಾತುಕತೆ ನಡೆಸುತ್ತವೆ. ಆದ್ದರಿಂದ TLS 1.3 ಸೂಟ್ ಹೆಸರನ್ನು TLS 1.2 ಸೂಟ್ ಹೆಸರಿನೊಂದಿಗೆ ಸಮಾನ ಆಧಾರದಲ್ಲಿ ಹೋಲಿಸಲಾಗದು, ಎರಡೂ ಸಂರಚನಾ ಫೈಲ್‌ನ ಒಂದೇ ಕ್ಷೇತ್ರದಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡರೂ. ಎರಡು ಸ್ಟ್ರಿಂಗ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಹೋಲಿಸುವ ಆಡಿಟರ್ ಪ್ರೋಟೋಕಾಲ್ ಬೆಂಬಲಿಸದ ತೀರ್ಮಾನಕ್ಕೆ ಬರುತ್ತಾನೆ. ಮಾತುಕತೆಯಾದ ಗುಂಪು ಮತ್ತು ಸಹಿ ನಿಯತಾಂಕಗಳನ್ನೂ ಓದಿ, ಇಲ್ಲದಿದ್ದರೆ ಹೋಲಿಕೆ ಅಪೂರ್ಣ.
WireGuard ವಿರುದ್ಧ ಮಾರ್ಗವನ್ನು ಆರಿಸಿ ಮಾತುಕತೆಯನ್ನು ಬಹುತೇಕ ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ: ಪ್ರೋಟೋಕಾಲ್ ಸ್ಥಿರ ಅಲ್ಗಾರಿದಮ್ ಗುಂಪನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡು ಅನುಷ್ಠಾನಗಳು ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಅಥವಾ ಇಲ್ಲ. ಇದು ಕಾನೂನುಬದ್ಧ ವಿನ್ಯಾಸ ಆಯ್ಕೆ, ಮತ್ತು WireGuard ಯಾವ ಸೂಟ್ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಹೋಲಿಕೆಗೆ ಯೋಗ್ಯವಾದ ಉತ್ತರವಿಲ್ಲ ಎಂದೂ ಅರ್ಥ. ನೀವು ಅದನ್ನು ಆಡಿಟ್ ಮಾಡುತ್ತಿದ್ದರೆ, ವಿವರಣೆಯನ್ನು ಒಮ್ಮೆ ಓದಿ ನಂತರ ಅದರ ಸುತ್ತಲಿನ ಕೀ ನಿರ್ವಹಣೆಯನ್ನು ಆಡಿಟ್ ಮಾಡಿ, ಮಾತುಕತೆಯ ಬದಲು.
ಪದರವು ಪದಕೋಶವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ
IPsec ನಿಯೋಜನೆ ಎರಡು ಬಾರಿ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ: ನಿಯಂತ್ರಣ ಚಾನೆಲ್‌ಗಾಗಿ IKE ಪ್ರಸ್ತಾವ ಮತ್ತು ಡೇಟಾಗಾಗಿ ESP ರೂಪಾಂತರ, ಮತ್ತು ಎರಡೂ ಕಾನೂನುಬದ್ಧವಾಗಿ ಭಿನ್ನವಾಗಿರಬಹುದು. ಮೊದಲನೆಯದನ್ನು ಓದಿ ಎರಡನೆಯದನ್ನು ವಿವರಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸುವುದು ಆಡಿಟ್ ಸಮಯದಲ್ಲಿ ಗೊಂದಲದ ಸಾಮಾನ್ಯ ಮೂಲ, ಏಕೆಂದರೆ ಸಂರಚನಾ ಫೈಲ್ ಎರಡನ್ನೂ ಉಲ್ಲೇಖಿಸುತ್ತದೆ ಮತ್ತು ಆಸಕ್ತಿದಾಯಕವಾದುದು ಎರಡನೆಯದು.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
ಒಂದು ಗ್ರಂಥಾಲಯದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಹೆಸರು ಇನ್ನೊಂದು ಡೇಟಾ ಮಾರ್ಗಕ್ಕೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅನುಷ್ಠಾನಗೊಳ್ಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ನಮ್ಮ ಉತ್ಪನ್ನ AES-256 ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬ ಹೇಳಿಕೆ ಕೇಳಲು ತೋರುವುದಕ್ಕಿಂತ ದುರ್ಬಲ, ಮತ್ತು ಆದ್ದರಿಂದ ಪರಸ್ಪರ ಕಾರ್ಯಸಾಧ್ಯತೆಯ ಸಮಸ್ಯೆ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡೂ ಕಡೆ ಎಲ್ಲಾ ಹಳೆಯ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಬದಲು ನಿರ್ವಹಿಸಲಾದ ಛೇದನವನ್ನು ಕಂಡುಹಿಡಿಯುವ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ.
TLS 1.3 ವಿವರಣೆ ಈ ಪ್ರತ್ಯೇಕತೆಯ ಅತ್ಯಂತ ಸ್ಪಷ್ಟ ಪ್ರಕಟಿತ ಉದಾಹರಣೆ, ಏಕೆಂದರೆ ಅದು ಸೂಟ್ ಅನ್ನು ಜೋಡಿಯಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿ ಉಳಿದದ್ದನ್ನು ತನ್ನದೇ ಮಾತುಕತೆಗೆ ಸ್ಥಳಾಂತರಿಸುತ್ತದೆ. ಆ ಆಕಾರ ಪರಿಚಿತವಾದ ಮೇಲೆ IPsec ಪ್ರಸ್ತಾವ ಮತ್ತು WireGuard ನ ಒಂದೇ ಸ್ಥಿರ ಗುಂಪು ಒಂದೇ ಕಲ್ಪನೆಯ ರೂಪಾಂತರಗಳಾಗಿ ಓದಲ್ಪಡುತ್ತವೆ.
ಮಾತುಕತೆಯಾದ ಫಲಿತಾಂಶವನ್ನು ಓದಿ, ನಂತರ ನಿಲ್ಲಿಸಿ
ಸಂರಚಿಸಿದ ಪ್ರಸ್ತಾವ ಎರಡು ಸಹವರ್ತಿಗಳು ಏನನ್ನು ಆರಿಸಿದರು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ. ಜೀವಂತ ಅಧಿವೇಶನ ಉತ್ತರವನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಪ್ರತಿ ಮುಖ್ಯ ಅನುಷ್ಠಾನವೂ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯದೆ ಅದನ್ನು ವರದಿ ಮಾಡಬಹುದು.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ನೀಡಿದ ಪಟ್ಟಿಯ ಬದಲು ಆಯ್ಕೆಯಾದ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಓದಿ. ಉತ್ತರವು ನೀತಿ ಉದ್ದೇಶಿಸಿದ್ದಕ್ಕಿಂತ ದುರ್ಬಲವಾಗಿದ್ದರೆ, ತಿದ್ದುಪಡಿ ಒಂದು ಕಡೆಯ ಪ್ರಸ್ತಾವ ಸಂರಚನೆಯಲ್ಲಿದೆ, ಮತ್ತು ಆಧುನಿಕ ಅನುಷ್ಠಾನಗಳಲ್ಲಿ ಅಸಾಮರಸ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಮೌನ ಕುಸಿತವಲ್ಲ, ವಿಫಲ ಮಾತುಕತೆಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ.
ನಂತರ ಸೂಟ್ ಏನನ್ನು ಆವರಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ಮಾರ್ಗಗಳು, ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿಗಳು, ಲಾಗಿಂಗ್ ಮತ್ತು ಧಾರಣೆ ತಮ್ಮದೇ ಪರಿಶೀಲನೆಯಿರುವ ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳು, ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ವ್ಯವಸ್ಥೆ ಅವುಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಸೈಫರ್ ಚರ್ಚೆ ಯೋಗ್ಯ, ಆದರೆ ಅದು ಹೆಚ್ಚಿನ ಜನರು ನಿಜವಾಗಿ ಕೇಳುವ ಪ್ರಶ್ನೆಗಿಂತ ಸಣ್ಣ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.
ಪದಕೋಶವನ್ನು ನಿಖರವಾಗಿ ಇರಿಸಿ, ವಾದ ಚಿಕ್ಕದಾಗುತ್ತದೆ. ಸೂಟ್ ಎಂದರೆ ಪದರದ ಮೇಲಿನ ಪಾತ್ರಗಳ ಗುಂಪು, ಸೈಫರ್ ಒಂದು ಘಟಕ, ಮತ್ತು ಮಾತುಕತೆಯಾದ ಫಲಿತಾಂಶವೇ ನಿಜವಾಗಿ ನಿಮ್ಮಲ್ಲಿರುವ ಸಂಪರ್ಕವನ್ನು ವಿವರಿಸುವ ಏಕೈಕ ವಸ್ತು. ಹೋಲಿಕೆಯಲ್ಲಿ ಉಳಿದದ್ದೆಲ್ಲ ಅಲಂಕಾರ.