ವಿಫಲವಾದ VPN ಹ್ಯಾಂಡ್‌ಶೇಕ್ ನಿಜವಾಗಿಯೂ ಡೌನ್‌ಗ್ರೇಡ್ ದಾಳಿಯೇ?

ದೋಷದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಂದೇಶವನ್ನು ನೋಡುವವರೆಗೆ ದಾಳಿಯಂತೆ ಭಾಸವಾಗುತ್ತದೆ, ಮತ್ತು ಹೆಚ್ಚಿನ ಸಮಯ ಅದು ಅಂಕಗಣಿತ: ಹಂಚಿಕೆಯ ಪ್ರಸ್ತಾಪವಿಲ್ಲ, ಅವಧಿ ಮುಗಿದ ಪ್ರಮಾಣಪತ್ರ, ಅಥವಾ ಎಂದೂ ಬಾರದ ಪ್ಯಾಕೆಟ್. ಡೌನ್‌ಗ್ರೇಡ್ ದಾಳಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ವಿಷಯ: ಎದುರಾಳಿ ಎರಡೂ ತುದಿಗಳನ್ನು ಅವರು ಆಯ್ಕೆ ಮಾಡುತ್ತಿದ್ದಕ್ಕಿಂತ ದುರ್ಬಲ ವರ್ತನೆಯತ್ತ ತಳ್ಳುತ್ತಾನೆ, ಮತ್ತು ಅದು ಬೇರೆ ಸಾಕ್ಷ್ಯ ಬಿಡುತ್ತದೆ. ಪ್ರತಿ ವೈಫಲ್ಯವನ್ನೂ ದುರುದ್ದೇಶ ಎಂದು ಪರಿಗಣಿಸಿದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಬಲಿಪಶುವನ್ನು ಹುಡುಕುತ್ತೀರಿ, ಆದರೆ ನಿಜವಾದ ಡೌನ್‌ಗ್ರೇಡ್ ಅನ್ನು ಕಾನ್ಫಿಗರೇಶನ್ ದೋಷ ಎಂದು ಪರಿಗಣಿಸಿದರೆ ದುರ್ಬಲ ಫಲಿತಾಂಶ ಹಾಗೆಯೇ ಉಳಿಯುತ್ತದೆ. ಎರಡೂ ತಪ್ಪುಗಳ ಬೆಲೆ ಬೇರೆ, ಮತ್ತು ಒಂದನ್ನು ಮಾತ್ರ ಅಗ್ಗವಾಗಿ ಸರಿಪಡಿಸಬಹುದು.

ಡೌನ್‌ಗ್ರೇಡ್ ದಾಳಿ ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ

ಗುರಿ ಸೈಫರ್ ಒಡೆಯುವುದಲ್ಲ ಮತ್ತು ಕೀಲಿಯನ್ನು ಊಹಿಸುವುದಲ್ಲ. ಗುರಿ ಮಾತುಕತೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವುದು, ಎರಡೂ ಪಕ್ಷಗಳು ದಾಳಿಕೋರನು ನಿಭಾಯಿಸಬಲ್ಲ ಹಳೆಯ ಆವೃತ್ತಿ ಅಥವಾ ದುರ್ಬಲ ಅಲ್ಗಾರಿದಮ್‌ನಲ್ಲಿ ನಿಲ್ಲುವಂತೆ, ಅಥವಾ ಒಂದು ಪಕ್ಷ ಇನ್ನೊಂದು ಅದನ್ನಷ್ಟೇ ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ನಂಬುವಂತೆ ಮಾಡುವುದು.

ಬದಲಾಗುವುದು ಒಪ್ಪಂದ, ದೃಢೀಕರಣವಲ್ಲ. ದಾಳಿಕೋರನು ಪತ್ತೆಯಾಗದೆ ಕೊಡುಗೆಯನ್ನು ಬದಲಿಸಬಲ್ಲರೆ, ಪಕ್ಷಗಳು ಇನ್ನೂ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪೂರ್ಣಗೊಳಿಸಿ ಪರಸ್ಪರ ದೃಢೀಕರಿಸಬಹುದು, ಆದರೆ ದಾಳಿಕೋರನಿಗೆ ಇಷ್ಟವಾದ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ. ಆದ್ದರಿಂದ ಆಸಕ್ತಿಕರ ಪ್ರಶ್ನೆ ಎಂದರೆ ಮಾತುಕತೆಯೇ ಸಮಗ್ರತಾ ರಕ್ಷಣೆಯಲ್ಲಿ ಒಳಗೊಂಡಿದೆಯೇ.

ಮಾತುಕತೆಯನ್ನೇ ದೃಢೀಕರಿಸಬೇಕಾದದ್ದು ಏಕೆ

TLS 1.3 ಆ ರಕ್ಷಣೆಯನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ. ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸೂಚಿಸಿದ ಕ್ಲೈಂಟ್ ಮೌನವಾಗಿ ಹಿಂದೆ ಸರಿದ ಸರ್ವರ್ ಅನ್ನು ಗುರುತಿಸಬಲ್ಲದು, ಏಕೆಂದರೆ ಸರ್ವರ್‌ನ ಯಾದೃಚ್ಛಿಕ ಮೌಲ್ಯವು 1.2 ಅಥವಾ ಕೆಳಗೆ ಮಾತುಕತೆ ನಡೆಸುವಾಗ ಸ್ಥಿರ ಮಾದರಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಅದನ್ನು ಕಂಡಾಗ ನಿಲ್ಲಿಸಬೇಕು. ಪೂರ್ಣ ಟ್ರಾನ್ಸ್‌ಕ್ರಿಪ್ಟ್ ಸಹ ಅಂತಿಮ ಸಂದೇಶಗಳಿಂದ ಆವರಿಸಲ್ಪಟ್ಟಿದೆ, ಆದ್ದರಿಂದ ಮಾತುಕತೆಯ ಎಲ್ಲಾದರೂ ಬದಲಾವಣೆ ನಂತರ ವಿಫಲವಾಗುತ್ತದೆ, ಮೌನವಾಗಿ ದಾಟುವುದಿಲ್ಲ.

ಹಳೆಯ ಪ್ರೋಟೋಕಾಲ್ ಆವೃತ್ತಿಗಳ ಕಥೆಗಳು ದುರ್ಬಲವಾಗಿದ್ದವು, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಫಾಲ್‌ಬ್ಯಾಕ್ ನಿಯಮಗಳು ಮುಖ್ಯ. ಅದೇ ಕಾನ್ಫಿಗರೇಶನ್ನಲ್ಲಿ TLS 1.0 ಎಂಡ್‌ಪಾಯಿಂಟ್ ಡೌನ್‌ಗ್ರೇಡ್ ದಾಳಿಯಲ್ಲ; ಅದು ನೀವು ಅನುಮತಿಸಲು ಆಯ್ಕೆ ಮಾಡಿದ ಅನುಮತಿಸಿದ ಫಲಿತಾಂಶ. ವ್ಯತ್ಯಾಸ ಎಂದರೆ ದುರ್ಬಲ ಫಲಿತಾಂಶ ರಕ್ಷಿತ ನಿರ್ಧಾರದಿಂದ ಬಂತೋ ಅಥವಾ ಮಧ್ಯವರ್ತಿ ಪ್ರಭಾವಿಸಬಹುದಾದ ಅರಕ್ಷಿತ ಮಾರ್ಗದಿಂದ ಬಂತೋ. ಹೀಗೆ ಹೇಳಿದರೆ ಹೆಚ್ಚಿನ ಘಟನೆಗಳು ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರಶ್ನೆಯಾಗಿ ಪರಿವರ್ತನೆಯಾಗುತ್ತವೆ.

IKEv2 ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ ಆದರೆ ಅದೇ ಕಲ್ಪನೆಯ ಮೇಲೆ ನಿಂತಿದೆ. ಪ್ರಸ್ತಾಪವು ನಂತರ ಎರಡೂ ಪಕ್ಷಗಳನ್ನು ದೃಢೀಕರಿಸುವ ವಿನಿಮಯದಲ್ಲಿ ಸಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಮರುಬರೆಯುವ ಮಧ್ಯ-ಬಾಕ್ಸ್ ದೃಢೀಕರಣವನ್ನು ಮಾರ್ಗದರ್ಶನ ಮಾಡುವ ಬದಲು ಒಡೆಯುತ್ತದೆ. OpenVPN ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ತನ್ನ ಮಾತುಕತೆಯನ್ನು TLS ನಿಂದ ರಕ್ಷಿಸಿ ನಂತರ ಆ ಚಾನೆಲ್‌ನಿಂದ ಡೇಟಾ ಚಾನೆಲ್‌ನ ಸೈಫರ್‌ಗಳನ್ನು ಒಪ್ಪುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಯಂತ್ರಣ ಚಾನೆಲ್‌ನ ಲಾಗ್ ಸಾಲು ಆಸಕ್ತಿಕರ.

ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಹೊಂದಾಣಿಕೆ ದಾಳಿಯಲ್ಲ

ನಿರ್ವಾಹಕರು ದಾಖಲಿತ ಕ್ಲೈಂಟ್ ಅನ್ನು ಬೆಂಬಲಿಸಲು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹಳೆಯ ಆಯ್ಕೆಗಳನ್ನು ಅನುಮತಿಸಬಹುದು, ಮತ್ತು ಆ ನಿರ್ಧಾರ ಕಾನ್ಫಿಗರೇಶನ್ನಲ್ಲಿ ಕಾಣುತ್ತದೆ. ದಾಳಿಕೋರನು ಆ ಕಾನ್ಫಿಗರೇಶನ್ ರಚಿಸಲಾರನು; ಕೊಡುಗೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಲು ಅನುಮತಿಸುವ ಮಾರ್ಗವನ್ನು ಮಾತ್ರ ಬಳಸಬಹುದು.

ಅಪಾಯಕಾರಿ ದುರಸ್ತಿ ಎಂದರೆ ವ್ಯತ್ಯಾಸದ ಸಾಕ್ಷ್ಯವನ್ನು ತೆಗೆದುಹಾಕುವುದು. ಪ್ರತಿ ಹಳೆಯ ಆಯ್ಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು, ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಅಥವಾ ದೋಷ ಮಾಯವಾಗಲು ಯಾವುದೇ ಸೈಫರ್ ಸ್ವೀಕರಿಸುವುದು ಎಂಡ್‌ಪಾಯಿಂಟ್ ಒಪ್ಪುವ ವ್ಯಾಪ್ತಿಯನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ ಮತ್ತು ದುರ್ಬಲ ಫಲಿತಾಂಶವನ್ನು ವರದಿ ಮಾಡುತ್ತಿದ್ದ ಪರಿಶೀಲನೆಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

ಒಂದು ಹಳೆಯ ಆಯ್ಕೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬೇಕಾದರೆ, ಕಾರಣ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ಕಾನ್ಫಿಗರೇಶನ್ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಹೆಸರಿಸಿ, ನಂತರ ಆಯ್ಕೆಯನ್ನು ಅದು ಬೇಕಾದ ಪ್ರೊಫೈಲ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ಒಂದು ಶ್ರೋತೃಕ್ಕೆ ಸೀಮಿತವಾದ ಹೊಂದಾಣಿಕೆ ವಿನಾಯಿತಿ ಆಡಿಟ್ ಮಾಡಬಹುದಾದದ್ದು; ಜಾಗತಿಕವಾಗಿ ಅನ್ವಯಿಸಿದ್ದು ಯಾರೂ ಆಯ್ಕೆ ಮಾಡಿದ್ದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳದ ದುರ್ಬಲ ಡೀಫಾಲ್ಟ್ ಮಾತ್ರ.

ಕಾರಣ ಹೆಸರಿಸುವ ಮೊದಲು ವೈಫಲ್ಯವನ್ನು ಓದಿ

ಯಾವುದೇ ಬದಲಾವಣೆಗೆ ಮೊದಲು ನಿಖರ ದೋಷ ಸ್ಟ್ರಿಂಗ್, ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಸಮಯವನ್ನು ಉಳಿಸಿ. ನಂತರ ವರ್ಗೀಕರಿಸಿ: ಪಕ್ಷಗಳು ಪ್ರಸ್ತಾಪದ ಬಗ್ಗೆ ಒಪ್ಪಲಿಲ್ಲವೇ, ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗ ವಿಫಲವಾಯಿತೇ, ಅಥವಾ ಒಂದು ಪಕ್ಷ ಮೊದಲು ಸ್ವೀಕರಿಸುತ್ತಿದ್ದ ನಿಯತಾಂಕವನ್ನು ನಿರಾಕರಿಸಿತೇ?

ಪ್ರಸ್ತಾಪದ ಹೊಂದಾಣಿಕೆ ಇಲ್ಲದಿರುವಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ದೋಷಿ ಆವೃತ್ತಿಗಳು ಅಥವಾ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಹೆಸರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಬಾರಿ ಅದೇ ಹಂತದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ರೂಟಿಂಗ್ ಅಥವಾ MTU ಸಮಸ್ಯೆ ನಿಂತುಹೋಗುತ್ತದೆ ಅಥವಾ ಸಮಯ ಮೀರಿ ಮುಗಿಯುತ್ತದೆ, ಮತ್ತು ಇದು ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಅನುಸಾರವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಅವಧಿ ಮುಗಿದ ಪ್ರಮಾಣಪತ್ರ ಮಾತುಕತೆಯಲ್ಲ, ಪರಿಶೀಲನೆಯ ದೋಷ ನೀಡುತ್ತದೆ.

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ದಾಳಿಕೋರನ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಮೊದಲ ವೈಫಲ್ಯದಲ್ಲೇ ದುರುದ್ದೇಶಪೂರ್ಣ ಕಾರಣವನ್ನು ಆರೋಪಿಸುವುದೇ ತಪ್ಪು, ಏಕೆಂದರೆ ಅದು ನಾಳೆ ಮತ್ತೆ ವಿಫಲವಾಗುವ ನಿರ್ಣಾಯಕ ದೋಷವನ್ನು ಮುಚ್ಚಿಡುತ್ತದೆ.

ನಿಜವಾಗಿ ಏನು ಆಯ್ಕೆಯಾಯಿತು ಎಂದು ದೃಢೀಕರಿಸಿ

ಯಾವುದೇ ತಿದ್ದುಪಡಿಯ ನಂತರ ಸಂಪರ್ಕ ಏರಿತು ಎಂದು ನಂಬುವ ಬದಲು ಮಾತುಕತೆಯ ಫಲಿತಾಂಶವನ್ನು ಓದಿ. ಪರಿಶೀಲನೆ ತೆಗೆದುಹಾಕಿದ್ದರಿಂದ ಯಶಸ್ವಿಯಾದ ಸಂಪರ್ಕವೇ ನೀವು ತಪ್ಪಿಸಲು ಬಯಸಿದ ಫಲಿತಾಂಶ. ಕೆಳಗಿನ ಎರಡು ಆದೇಶಗಳು TLS ಮುಂಭಾಗದ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಆಯ್ಕೆಯಾದ ಆವೃತ್ತಿ ಮತ್ತು ಸೈಫರ್, ಜೊತೆಗೆ OpenVPN ಸರ್ವರ್ ಲಾಗ್‌ನ ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಸಾಲನ್ನು ತೋರಿಸುತ್ತವೆ.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

ಫಲಿತಾಂಶವನ್ನು ನೀವು ಉದ್ದೇಶಿಸಿದ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಹೋಲಿಸಿ, ಈಗ ಸಂಪರ್ಕವಾಗುತ್ತಿರುವುದಕ್ಕಲ್ಲ. ಆಯ್ಕೆಯಾದ ಆವೃತ್ತಿ ಅನುಮತಿಸಿದ ಕನಿಷ್ಠಕ್ಕಿಂತ ಹಳೆಯದಾಗಿದ್ದರೆ, ಪ್ರೊಫೈಲ್ ಅಥವಾ ಫಾಲ್‌ಬ್ಯಾಕ್ ಪಟ್ಟಿ ನೋಡುವ ಸ್ಥಳ, ಮತ್ತು ಉತ್ತರ ಆ ಪಟ್ಟಿಯನ್ನು ಸರಿಪಡಿಸುವುದು, ದಾಳಿ ಘೋಷಿಸಿ ಸುತ್ತಲೂ ಎಲ್ಲವನ್ನೂ ಮತ್ತೆ ಕಟ್ಟುವುದಲ್ಲ.