WSS ಸುರಂಗದ ಗೂಢಲಿಪೀಕರಣವು ಆ್ಯಪ್ನಲ್ಲಿ ಅಲ್ಲ, TLS ಟರ್ಮಿನೇಟರ್ನಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ
ಒಂದು wss:// URL ಒಂದು ಹಾಪ್ನಲ್ಲಿ TLS ಇರುವುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಪೇಲೋಡ್ಗೆ ತನ್ನದೇ ಗೂಢಲಿಪೀಕರಣ ಇದೆಯೇ ಎಂಬುದು ಕ್ಲೈಂಟ್ ಒಳಗೆ ಏನು ಹಾಕುತ್ತದೆ ಮತ್ತು ಆ TLS ಅನ್ನು ಯಾರು ಮುಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಸುರಕ್ಷಿತ WebSocket ಒಳಗೆ ಸಾಗಿಸುವ ಸುರಂಗವು ಕ್ಲೈಂಟ್ ಅದರೊಳಗೆ ಹಾಕಿದಷ್ಟೇ ಗೂಢಲಿಪೀಕರಣವನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಲ್ಲ. wss:// ಸ್ಕೀಮ್ TLS ಒಂದು ಹಾಪ್ನಲ್ಲಿ ಒಂದು ಸಂಪರ್ಕವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ. WebSocket ಸಂದೇಶಗಳ ಒಳಗಿನ ಬೈಟ್ಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿವೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಮಧ್ಯದಲ್ಲಿ ಏನಾದರೂ TLS ಮುಗಿಸಿದಾಗ ನಿಮ್ಮ ಟ್ರಾಫಿಕ್ ಯಾರು ಓದಬಹುದು ಎಂಬುದನ್ನು ಈ ವ್ಯತ್ಯಾಸವೇ ನಿರ್ಧರಿಸುತ್ತದೆ.
ಒಂದರಂತೆ ಕಾಣುವ ಎರಡು ಪದರಗಳು
ಸುರಕ್ಷಿತ WebSocket ಎಂದರೆ TLS, ಅದರ ಮೇಲೆ WebSocket ಹ್ಯಾಂಡ್ಶೇಕ್ ನಡೆಯುತ್ತದೆ, RFC 6455 ತನ್ನ ಸಂಪರ್ಕ ಮತ್ತು ಭದ್ರತಾ ವಿಭಾಗಗಳಲ್ಲಿ ವಿವರಿಸಿದಂತೆ. TLS ಪದರ ಸರ್ವರ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಗೂಢಲಿಪೀಕರಿಸುತ್ತದೆ, ನಂತರ WebSocket ಪದರ ಅಪ್ಲಿಕೇಶನ್ ಕಳುಹಿಸಲು ನಿರ್ಧರಿಸಿದ್ದನ್ನು ಫ್ರೇಮ್ ಮಾಡುತ್ತದೆ.
ಇವು ಎರಡು ಸ್ವತಂತ್ರ ನಿರ್ಧಾರಗಳು, ಮತ್ತು ಇಡೀ ಮಾರ್ಗದ ಮೇಲೆ ಒಂದೇ ಬೀಗ ಬರೆಯುವ ರೇಖಾಚಿತ್ರ ಎರಡನೆಯದನ್ನು ಮರೆಮಾಡುತ್ತದೆ. TLS ಸಂಪರ್ಕವನ್ನು ಯಾರು ಮುಗಿಸುತ್ತಾರೆ ಎಂದು ಕೇಳಿ. ನಂತರ ಕ್ಲೈಂಟ್ ಪ್ರತಿ ಸಂದೇಶದ ಒಳಗೆ ಏನು ಹಾಕುತ್ತದೆ ಎಂದು ಕೇಳಿ. ನಿಯೋಜನೆಯ ಬಗ್ಗೆ ಉಳಿದ ಎಲ್ಲವೂ ಈ ಎರಡು ಉತ್ತರಗಳಿಂದ ಬರುತ್ತದೆ.
ವಿನ್ಯಾಸ A: ಸಾಗಣೆಯೇ ಏಕೈಕ ಗೂಢಲಿಪೀಕರಣ
ಸರಳ ವಿನ್ಯಾಸದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಕಚ್ಚಾ IP ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ತೆಗೆದುಕೊಂಡು WebSocket ಸಂದೇಶಗಳಲ್ಲಿ ಸುತ್ತುತ್ತದೆ. ಒಳಗೆ ಏನೂ ಗೂಢಲಿಪೀಕರಿಸಲ್ಪಟ್ಟಿಲ್ಲ, ಆದ್ದರಿಂದ TLS ಸೆಷನ್ ಹೊಂದಿರುವ ಘಟಕವು ಸ್ಪಷ್ಟ ಪಠ್ಯದ ಪೇಲೋಡ್ಗಳನ್ನು ಓದುತ್ತದೆ. ಆ ಘಟಕ ನಿಮ್ಮದೇ ಸುರಂಗ ಸರ್ವರ್ ಆಗಿದ್ದರೆ, ಇದೇ ಉದ್ದೇಶಿತ ಅಂತ್ಯಬಿಂದು ಮತ್ತು ವಿನ್ಯಾಸ ಸುಸಂಗತವಾಗಿದೆ, ಏಕೆಂದರೆ ಸರ್ವರ್ ಯಾವಾಗಲೂ ಟ್ರಾಫಿಕ್ ನೋಡಲಿತ್ತು.
ಮಾರ್ಗದಲ್ಲಿ ತಪಾಸಣೆ ಪ್ರಾಕ್ಸಿ ಕುಳಿತು ಕ್ಲೈಂಟ್ ನಂಬುವ ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ TLS ಮುಗಿಸಿದಾಗ ಇದು ಬೇರೆ ವ್ಯವಸ್ಥೆಯಾಗುತ್ತದೆ. ಆ ಪ್ರಾಕ್ಸಿ ಈಗ ಸರ್ವರ್ ಹೊಂದಿರುತ್ತಿದ್ದ ಅದೇ ಸ್ಪಷ್ಟ ಪಠ್ಯವನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು WebSocket ಫ್ರೇಮಿಂಗ್ನ ಯಾವುದೇ ಪ್ರಮಾಣ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ನ ವಿಶ್ವಾಸ ಸಂಗ್ರಹವು ಈ ಫಲಿತಾಂಶವನ್ನು ಸುರಂಗ ತೆರೆಯುವ ಬಹಳ ಮೊದಲೇ ನಿರ್ಧರಿಸಿತ್ತು, ಏಕೆಂದರೆ ಅದು ಆ ಹೆಸರಿಗೆ ಆ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸ್ವೀಕರಿಸಲು ಆಯ್ಕೆ ಮಾಡಿತ್ತು. ಪ್ರಾಕ್ಸಿ ವಿನಂತಿಸಿದ ಹೋಸ್ಟ್ ಮತ್ತು ಪ್ರತಿ ಸಂದೇಶದ ಗಾತ್ರವನ್ನೂ ನೋಡುತ್ತದೆ, ಇದು ಇನ್ನೇನೂ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡದೆ ಬಹಳ ಚಟುವಟಿಕೆಯ ಬೆರಳಚ್ಚು ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಕು.
ವಿನ್ಯಾಸ B: ಪೇಲೋಡ್ ತನ್ನದೇ ಕೀಲಿಗಳನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತದೆ
ಎರಡನೆಯ ವಿನ್ಯಾಸದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ತನ್ನ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ತನ್ನದೇ ಪೀರ್ ಗುರುತು ಮತ್ತು ಕೀಲಿ ವಿನಿಮಯ ಹೊಂದಿರುವ VPN ಪ್ರೋಟೋಕಾಲ್ನಿಂದ ಗೂಢಲಿಪೀಕರಿಸಿ ದೃಢೀಕರಿಸುತ್ತದೆ, ನಂತರ ಫಲಿತಾಂಶವನ್ನು WebSocket ಸಂದೇಶಗಳ ಒಳಗೆ ಸಾಗಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಹೊರಗಿನ TLS ಮುಗಿಸುವುದು ಟ್ರಾಫಿಕ್ ಅಲ್ಲ, ಸೈಫರ್ಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಬಯಲಿಗೆಳೆಯುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಸಂದೇಶಗಳ ಗಾತ್ರ ಮತ್ತು ಸಮಯವನ್ನು ನೋಡಬಹುದು, ಪೇಲೋಡ್ನಲ್ಲಿ ಬೇರೇನೂ ಇಲ್ಲ. ಇದು ತುಂಬಾ ಚಿಕ್ಕ ಒಡ್ಡುವಿಕೆ, ಮತ್ತು ಇದು ವಿಮರ್ಶೆಯಲ್ಲಿ ಹೆಸರಿಸಲು ಯೋಗ್ಯವಾದ ಮೆಟಾಡೇಟಾ, ಪಕ್ಕಕ್ಕೆ ತಳ್ಳುವಂತಹದ್ದಲ್ಲ.
ಒಳಗಿನ ಪ್ರೋಟೋಕಾಲ್ನ ಸ್ವಂತ ಅಂತ್ಯಬಿಂದುಗಳು ಇನ್ನೂ ಸ್ಪಷ್ಟ ಪಠ್ಯವನ್ನು ನೋಡುತ್ತವೆ, ಇದೇ ವ್ಯವಸ್ಥೆಯ ಉದ್ದೇಶ ಮತ್ತು ಅದರ ಮಿತಿಯೂ ಹೌದು. ಅಂತ್ಯಬಿಂದುವಿನಲ್ಲಿನ ಘಟಕಕ್ಕೆ ಗೂಢಲಿಪೀಕರಣದ ಮೊದಲು ಅಥವಾ ಡೀಕ್ರಿಪ್ಶನ್ ನಂತರ ಡೇಟಾ ಓದಲು ಅಧಿಕಾರವಿದ್ದರೆ, ಹೆಚ್ಚುವರಿ ಪದರ ಅದನ್ನು ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ. ಕೀಲಿಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಾಫ್ಟ್ವೇರ್ ಮುಖ್ಯವಾದ ಗಡಿಯಾಗಿ ಉಳಿಯುತ್ತವೆ.
VPN ಲೇಬಲ್, ಪರಿಚಿತ ಕ್ಲೈಂಟ್ ಐಕಾನ್ ಅಥವಾ ಮಾರ್ಕೆಟಿಂಗ್ ಪುಟವು ಈ ವಿನ್ಯಾಸ ಇದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ. ಪೇಲೋಡ್ ಸ್ವರೂಪವನ್ನು ಓದುವುದು ಸಾಕ್ಷಿ.
ಸ್ಪಷ್ಟ ಪಠ್ಯ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪತ್ತೆ ಮಾಡಿ
URL ಸ್ಕೀಮ್ ನಿಮಗೆ ಒಂದು ಸತ್ಯವನ್ನು ನೀಡುತ್ತದೆ, ಉಳಿದದ್ದನ್ನು ಇಂಟರ್ಫೇಸ್ಗಳಿಂದ ಪಡೆಯಿರಿ. ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದೂ ಮುಂದಿನದನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ:
ss -tnp | grep -E ':(443|8443)\b' ip -br link show type tun openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief tcpdump -ni tun0 -c 5 -X
ಹೊರಗಿನ ಸಂಪರ್ಕದಿಂದ ಪ್ರಾರಂಭಿಸಿ. TLS ಪೋರ್ಟ್ಗೆ ಒಂದು ದೀರ್ಘಕಾಲಿಕ TCP ಸೆಷನ್ ಇರುವುದೇ WebSocket ವಾಹಕದ ರೂಪ, ಮತ್ತು ಸಂಬಂಧವಿಲ್ಲದ ಹೋಸ್ಟ್ಗೆ ಎರಡನೆಯ ಸೆಷನ್ ಆಳವಾಗಿ ನೋಡುವ ಮೊದಲು ವಿವರಣೆಗೆ ಅರ್ಹವಾಗಿದೆ. ನಂತರ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಹುಡುಕಿ, ಏಕೆಂದರೆ tun ಅಥವಾ tap ಸಾಧನವು ಕ್ಲೈಂಟ್ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡುವ ಬದಲು IP ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ.
ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿನ ಕ್ಯಾಪ್ಚರ್ ಸಾಮಾನ್ಯವಾಗಿ ಪೇಲೋಡ್ ಪ್ರಶ್ನೆಯನ್ನು ಬಗೆಹರಿಸುತ್ತದೆ. ಅಲ್ಲಿ ಓದಬಹುದಾದ ಹೆಡರ್ಗಳಿದ್ದರೆ ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ಗಳು ಎಂದಿಗೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಗೂಢಲಿಪೀಕರಿಸಲ್ಪಟ್ಟಿಲ್ಲ ಎಂದರ್ಥ, ಹೆಚ್ಚಿನ ಎಂಟ್ರೊಪಿಯ ಪೇಲೋಡ್ಗಳಿದ್ದರೆ ಗೂಢಲಿಪೀಕರಿಸಲ್ಪಟ್ಟಿವೆ ಎಂದರ್ಥ. ಹೊರಗಿನ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಕ್ಯಾಪ್ಚರ್ ಪುನರಾವರ್ತಿಸಿ ಎರಡನ್ನೂ ಹೋಲಿಸಿ: ಎರಡೂ ಯಾದೃಚ್ಛಿಕವಾಗಿ ಕಂಡರೆ, ಒಳಗಿನ ಪದರವು ಹೊರಗಿನ ಪದರ ರದ್ದು ಮಾಡಲಾಗದ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿದೆ.
ನೀವು ನಿಜವಾಗಿ ನೀಡಿದ ವಿಶ್ವಾಸವನ್ನು ಪರಿಶೀಲಿಸಿ
ಸ್ಥಾಪಿತ ಕಾರ್ಪೊರೇಟ್ ರೂಟ್ ಪ್ರಮಾಣಪತ್ರವು ಕ್ಲೈಂಟ್ನ ವಿಶ್ವಾಸ ಸಂಗ್ರಹದ ಬಗ್ಗೆ ಸತ್ಯ, ಯಾವುದೇ ಪ್ರಾಕ್ಸಿ ಏನು ದಾಖಲಿಸುತ್ತದೆ ಅಥವಾ ಪರಿಶೀಲಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಹೇಳಿಕೆಯಲ್ಲ. CA ಇರುವುದರಿಂದ ವರ್ತನೆಯನ್ನು ಊಹಿಸುವ ಬದಲು ನಿಯೋಜಿತ ನೀತಿ ಮತ್ತು ನಿಜವಾದ ಸಂಪರ್ಕ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸಿ.
ನಿರ್ವಹಿಸಲಾದ ಸಾಧನಗಳಲ್ಲಿ, ಯಾವ ಘಟಕ TLS ಮುಗಿಸುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಪಿನ್ ಮಾಡಿದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆಯೇ ಅಥವಾ ಸಾರ್ವಜನಿಕವನ್ನು, ಮತ್ತು ಪೇಲೋಡ್ ಸ್ವರೂಪ ಏನು ಎಂದು ನಿರ್ವಾಹಕರನ್ನು ಕೇಳಿ. ಆ ಮೂರು ಉತ್ತರಗಳು ನಂತರ ನೀವು ಸಮರ್ಥಿಸಬಹುದಾದ ಸಂಶೋಧನೆಯನ್ನು ನೀಡುತ್ತವೆ.
ಫಲಿತಾಂಶವನ್ನು ತೀರ್ಪಿನ ಬದಲು ಗಡಿಯಾಗಿ ಬರೆಯಿರಿ. "TLS ತಪಾಸಣೆ ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ, ಮತ್ತು ಒಳಗಿನ ಪೇಲೋಡ್ ಕೇವಲ ಅಂತ್ಯಬಿಂದುಗಳಲ್ಲಿರುವ ಕೀಲಿಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಗೂಢಲಿಪೀಕರಿಸಲ್ಪಟ್ಟಿದೆ" ಎಂಬುದು ಪರಿಶೀಲಿಸಬಹುದಾದ ಹೇಳಿಕೆ, ಮತ್ತು ಮಾರಾಟಗಾರ ಬದಲಾದರೂ ಉಳಿಯುತ್ತದೆ. "WebSockets ಸುರಕ್ಷಿತ" ಉಳಿಯುವುದಿಲ್ಲ.