SSTP ಮತ್ತು SSL 3.0: ಲೇಬಲ್ ವಿರುದ್ಧ ಚರ್ಚಿಸಿದ ಆವೃತ್ತಿ

ಇಬ್ಬರು ವ್ಯಕ್ತಿಗಳು ಒಂದೇ SSTP ಜೋಡಣೆಯನ್ನು ನೋಡಿ ವಿರುದ್ಧ ತೀರ್ಮಾನಗಳಿಗೆ ಬರಬಹುದು. ಒಬ್ಬರು ಉತ್ಪನ್ನದ ದಾಖಲೆಯನ್ನು ಓದಿ, SSL ಅಕ್ಷರಗಳನ್ನು ಕಂಡು, ವರ್ಷಗಳ ಹಿಂದೆ ಹಿಂತೆಗೆದುಕೊಂಡ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಸುರಂಗವು ನಡೆಸುತ್ತಿದೆ ಎಂದು ಊಹಿಸುತ್ತಾರೆ. ಇನ್ನೊಬ್ಬರು ಆಧುನಿಕ ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ಗೆ ತೋರಿಸಿ ಪ್ರಶ್ನೆ ಮುಗಿಯಿತು ಎನ್ನುತ್ತಾರೆ. ಇಬ್ಬರೂ ಲೇಬಲ್‌ಗಳಿಂದ ವಾದಿಸುತ್ತಾರೆ, ಚರ್ಚಿಸಿದ ಆವೃತ್ತಿಯಿಂದ ಅಲ್ಲ, ಇವುಗಳಲ್ಲಿ ಒಂದೇ ಸಾಕ್ಷ್ಯ. ಮಾಡಲು ಯೋಗ್ಯವಾದ ಹೋಲಿಕೆ ಎಂದರೆ ಹೆಸರು ಏನನ್ನು ಭರವಸೆ ನೀಡುತ್ತದೆ ಮತ್ತು ಸೇವೆ ನಿಜವಾಗಿ ಏನನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ ಎಂಬುದರ ನಡುವಿನದು.

ಒಂದೇ ಪ್ರಶ್ನೆಗೆ ಎರಡು ಉತ್ತರಗಳು

ಲೇಬಲ್ ವಾದವನ್ನು ಹೇಳುವುದು ಸುಲಭ: SSTP ಅನ್ನು ಸುರಕ್ಷಿತ ಸಾಕೆಟ್ ಸುರಂಗ ಪ್ರೋಟೋಕಾಲ್ ಎಂದು ವಿವರಿಸಲಾಗುತ್ತದೆ, ಐತಿಹಾಸಿಕ ಹೆಸರು SSL ಎನ್ನುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಪರ್ಕ SSL 3.0 ಆಗಿರಬೇಕು. ಅದು ನಿಲ್ಲುವುದು ಹೆಸರು ನಿಜವಾಗಿ ಆ ಪರಂಪರೆಯಿಂದ ಬಂದಿರುವುದರಿಂದ ಮತ್ತು ಅದನ್ನು ಪುನರಾವರ್ತಿಸುವವರಲ್ಲಿ ಹೆಚ್ಚಿನವರು ಎಂದಿಗೂ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ನೋಡದಿರುವುದರಿಂದ. ತೀರ್ಮಾನವು ಎಚ್ಚರಿಕೆಯಿಂದ ಕೇಳಿಸುವುದರಿಂದಲೂ ಅದು ನಿಲ್ಲುತ್ತದೆ, ಅತ್ಯಂತ ಕೆಟ್ಟದನ್ನು ಊಹಿಸುವುದೇ ಸುರಕ್ಷಿತ ಆಯ್ಕೆ ಎಂಬಂತೆ. ಅತ್ಯಂತ ಕೆಟ್ಟದನ್ನು ಊಹಿಸುವುದು ಮತ್ತು ನಿಜವಾದ ಆವೃತ್ತಿಯನ್ನು ಅಳೆಯುವುದು ಬೇರೆ ಬೇರೆ ಕೆಲಸಗಳು, ಇವುಗಳಲ್ಲಿ ಒಂದೇ ಏನನ್ನಾದರೂ ಬದಲಿಸುತ್ತದೆ.

ಸಾಕ್ಷ್ಯದ ವಾದವು ಇನ್ನಷ್ಟು ಸಂಕುಚಿತ ಪ್ರಶ್ನೆ ಕೇಳುತ್ತದೆ. ಈ ಕ್ಲೈಂಟ್ ಮತ್ತು ಈ ಸರ್ವರ್ ಈ ತುದಿಬಿಂದುವಿನಲ್ಲಿ, ಈ ಸಮಯದಲ್ಲಿ ಯಾವ ಪ್ರೋಟೋಕಾಲ್ ಆವೃತ್ತಿಗೆ ಒಪ್ಪಿದವು? ಉತ್ತರ TLS ಅನ್ನು ಮುಗಿಸುವ ಸೇವೆಯಿಂದ ಬರುತ್ತದೆ, ಯಾವುದೇ ಮಾರ್ಕೆಟಿಂಗ್ ಪುಟದಿಂದ ಅಥವಾ ಹೋಲುವ ಹೆಸರಿನ ಸೈಟ್ ತಲುಪಿದ ಬ್ರೌಸರ್‌ನಿಂದ ಅಲ್ಲ.

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

ಸೇವೆ ನಿಜವಾಗಿ ಆಯ್ಕೆಮಾಡುವ ಆವೃತ್ತಿಯನ್ನು ಓದಿ

ಘಟಕಗಳನ್ನು ಹೆಸರಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ: ಕ್ಲೈಂಟ್ ಅನುಷ್ಠಾನ, ಸರ್ವರ್ ಅನುಷ್ಠಾನ, TLS ತುದಿಬಿಂದು, ಮತ್ತು ಅವುಗಳ ನಡುವೆ TLS ಅನ್ನು ಮುಗಿಸಿ ಮತ್ತೆ ಸ್ಥಾಪಿಸುವ ಎಲ್ಲವೂ. TLS ಅನ್ನು ಮುಗಿಸಿ ಬ್ಯಾಕೆಂಡ್‌ನೊಂದಿಗೆ ಸಾಮಾನ್ಯ HTTP ಮಾತನಾಡುವ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್, ನೀವು ಯಾವ ಸಾಧನದ ನೀತಿಯನ್ನು ಓದಬೇಕು ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

ಫಲಿತಾಂಶದ ಜೊತೆಗೆ ತುದಿಬಿಂದು ಮತ್ತು ಸಮಯವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ನಂತರ ನೀತಿ ಬದಲಾದರೆ ದಿನಾಂಕವಿಲ್ಲದ ವೀಕ್ಷಣೆ ನಿರುಪಯುಕ್ತವಾಗುತ್ತದೆ. ನಿಮಗೆ ಮುಖ್ಯವಾದ ಬಳಕೆದಾರರಿರುವ ಅದೇ ಜಾಲ ಮಾರ್ಗದಲ್ಲಿರುವ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ತಡೆಯುವ ಸಾಧನವು ತನ್ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ TLS ಅನ್ನು ಮುಗಿಸಬಹುದು. ಎರಡೂ ಸ್ಥಾನಗಳು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಮುಖ್ಯವಾದ ಘಟಕವನ್ನು ನೀವು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ. ಹೊಂದಿಕೆಯಾದರೆ, ಘೋಷಣೆಗಿಂತ ಸಾಕ್ಷ್ಯ ನಿಮ್ಮ ಬಳಿ ಇದೆ.

ದಾಖಲೆ ಕ್ಷೇತ್ರವನ್ನು ಚರ್ಚೆಯಿಂದ ಬೇರ್ಪಡಿಸಿ

ಒಂದು ಕ್ಷೇತ್ರದಲ್ಲಿ ಹಳೆಯದಾಗಿ ಕಾಣುವ ಆವೃತ್ತಿ ಸಂಖ್ಯೆ SSL 3.0 ಸೆಷನ್‌ಗೆ ಸಮಾನವಾದ ಸತ್ಯವಲ್ಲ. RFC 7568 ದಾಖಲೆ ಪದರದ ಆವೃತ್ತಿ ಮತ್ತು ಚರ್ಚಿಸಿದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೇರೆ ಬೇರೆ ವಿಷಯಗಳೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ, ಈ ಭೇದದಿಂದಲೇ ವಿಶ್ವಾಸದ ತಪ್ಪು ಉತ್ತರಗಳು ಬರುತ್ತವೆ. ಚರ್ಚಿಸಿದ ಪ್ರೋಟೋಕಾಲ್ ಓದಿ, ನಂತರ ಸೈಫರ್, ಆ ಮೇಲೆಯೇ ಸೆಷನ್ ಬಗ್ಗೆ ತೀರ್ಮಾನಕ್ಕೆ ಬನ್ನಿ.

ಅದೇ ದಾಖಲೆ ಪ್ರೋಟೋಕಾಲ್ ಬಗ್ಗೆ ಸ್ಪಷ್ಟವಾಗಿದೆ: SSL 3.0 ಬಳಸಬಾರದು, ಅದರ ಮೇಲೆ ಚರ್ಚೆ ಅಥವಾ ಹಿಂಜರಿಕೆ ನಿಷಿದ್ಧ. ಕಾರಣ POODLE ದಾಳಿ ಬಳಸಿಕೊಂಡ ಮುರಿದ CBC ರಚನೆ, ಅದು ಪ್ರೋಟೋಕಾಲ್‌ನ ಗುಣಲಕ್ಷಣ, ಒಂದು ಅನ್ವಯದ ಸಂರಚನೆ ಅಲ್ಲ.

ಆದ್ದರಿಂದ “ಈ ಹೊರೆಯನ್ನು ದುರುಪಯೋಗಪಡಿಸುವುದು ಕಷ್ಟ” ಎಂಬುದು SSL 3.0 ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಇರಿಸಲು ವಾದವಲ್ಲ. ಅಗತ್ಯ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ತೆಗೆಯುವುದು, ಒಂದು ಪ್ರದರ್ಶನದ ಬಗ್ಗೆ ಚರ್ಚೆಯನ್ನು ಗೆಲ್ಲುವುದಲ್ಲ.

SSL 3.0 ಅನ್ನು ನೀವು ಎತ್ತಿಹಿಡಿಯಬಹುದಾದ ನೀತಿಯೊಂದಿಗೆ ಹಿಂತೆಗೆದುಕೊಳ್ಳಿ

Windows ನಲ್ಲಿ Schannel ನ ಪ್ರೋಟೋಕಾಲ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು Protocols ಕೀ ಅಡಿಯಲ್ಲಿವೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಹಾಗೂ ಸರ್ವರ್ ಪಾತ್ರಗಳಿಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಓದಲಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಒಂದು ದಿಕ್ಕನ್ನು ಸರಿಪಡಿಸುವ ಬದಲಾವಣೆ ಇನ್ನೊಂದನ್ನು ಮುಟ್ಟದೆ ಬಿಡಬಹುದು. ಪ್ರಸ್ತುತ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಮರುಪ್ರಾರಂಭದ ಅಗತ್ಯಗಳನ್ನು Microsoft ದಾಖಲಿಸಿದೆ, ಅದೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿರುವ ತೃತೀಯ ಪಕ್ಷದ TLS ಗ್ರಂಥಾಲಯ ಅವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

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

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

ಬದಲಾವಣೆಯನ್ನು ಹೊಸ ಸಂಪರ್ಕಗಳೊಂದಿಗೆ ಸ್ವೀಕರಿಸಿ

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

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

ಫಲಿತಾಂಶವನ್ನು ಸೇವೆ, ಬ್ಯಾಕೆಂಡ್, ಅನುಮೋದಿತ ನೀತಿ ಮತ್ತು ಗಮನಿಸಿದ ಆವೃತ್ತಿ ಎಂದು ಬರೆಯಿರಿ. ಅಂತಹ ದಾಖಲೆ ಭದ್ರತಾ ಪ್ರಶ್ನೆಗೆ ನಿಖರವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ, ಲೇಬಲ್ ವಾದ ಅಥವಾ ಅಸೌಕರ್ಯದ ವಾದ ಅದನ್ನು ಎಂದಿಗೂ ಮಾಡುವುದಿಲ್ಲ.