ಒಂದು ಹಳೆಯ ಪೀರ್ TLS 1.0 ಅನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ: ವಿನಾಯಿತಿಯನ್ನು ಸೀಮಿತಗೊಳಿಸಿ, ಹೋಸ್ಟ್ ಅಲ್ಲ

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

ನಿರ್ದೇಶನವನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ವೈಫಲ್ಯವನ್ನು ಎರಡಾಗಿ ವಿಭಜಿಸಿ

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

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

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

ದುರ್ಬಲ ಮಿತಿಗೆ ಎರಡನೇ ಆಲಿಸುವವನೇ ಪ್ರಾಮಾಣಿಕ ಸ್ಥಳ

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

ವೇದಿಕೆ ಅನುಮತಿಸಿದರೆ, ಹಳೆಯ ಆಲಿಸುವವನನ್ನು ಪ್ರತ್ಯೇಕ ಪೋರ್ಟ್ನಲ್ಲಿ ಸ್ವಂತ ಸಂದರ್ಭವಾಗಿ ಚಲಾಯಿಸಿ, ಆ ಪೋರ್ಟ್ಗೆ ಸಾಧನದ ವಿಳಾಸದಿಂದ ಮಾತ್ರ ಅನುಮತಿ ನೀಡಿ, ಮತ್ತು ಮುಖ್ಯ ಸೇವೆಯನ್ನು ಬಿಡಿ. ಎರಡನೇ ಆಲಿಸುವವನು ಏಕೆ ಇದೆ ಎಂಬುದನ್ನು ಅದರ ಸಂರಚನೆ ಇರುವ ಫೈಲ್ನಲ್ಲಿ ಬರೆಯಿರಿ, ಇಲ್ಲದಿದ್ದರೆ ಭವಿಷ್ಯದ ಸ್ವಚ್ಛತೆ ಅದನ್ನು ಉಳಿದ ಕಸ ಎಂದು ಓದುತ್ತದೆ. ದುರ್ಬಲ ಮಿತಿಯು ಸಾಧನ ಮುಗಿಯುವಲ್ಲಿ ಮುಗಿದರೆ ಮಾತ್ರ ಈ ವಿಭಜನೆಗೆ ಅರ್ಥವಿದೆ.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

ಹಳೆಯ ಪೂರೈಕೆದಾರರ ಪ್ರಮಾಣಪತ್ರವು ನಿಜವಾಗಿ ಏನನ್ನು ಮುರಿಯುತ್ತದೆ

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

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

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

ಬ್ಯಾನರ್ ಅಲ್ಲ, ಮಾತುಕತೆ ನಡೆದ ಮೌಲ್ಯಗಳನ್ನು ಓದಿ

verbosity 4 ನಲ್ಲಿ ಎರಡೂ ತುದಿಗಳು ಒಪ್ಪಿದ ನಿಯಂತ್ರಣ ಚಾನಲ್ನ TLS ಆವೃತ್ತಿ ಮತ್ತು ಸೈಫರ್, ಮತ್ತು ಸೆಷನ್ನ ಡೇಟಾ ಸೈಫರ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತವೆ. ಆರಂಭಿಕ ಬ್ಯಾನರ್ ಬದಲು ಆ ಸಾಲುಗಳನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಬ್ಯಾನರ್ ಯಶಸ್ಸನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಅದರ ನಿಯಮಗಳನ್ನಲ್ಲ. ನಂತರ ಆಧುನಿಕ ಕ್ಲೈಂಟ್ ಅನ್ನು ಮುಖ್ಯ ಆಲಿಸುವವನಿಗೆ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಅದು ಇನ್ನೂ ಆಧುನಿಕ ಸೂಟ್ನಲ್ಲಿ ಇಳಿಯುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಹಂಚಿದ ಸಂರಚನೆಗೆ ಸೋರಿದ ವಿನಾಯಿತಿ ಮೊದಲು ಇಲ್ಲಿಯೇ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನೀವು ನಕಲಿಸುವ ಮೌಲ್ಯಗಳು ಮುಂದಿನ ಪರಿಶೀಲನೆಯ ಮೂಲಾಧಾರವಾಗುತ್ತವೆ.

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

ಪ್ರತಿ ವಿನಾಯಿತಿಗೂ ಮಾಲೀಕ ಮತ್ತು ದಿನಾಂಕ ಬೇಕು

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

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