OpenVPN ಪ್ಯಾಕೆಟ್ HMAC ದೃಢೀಕರಣ ವಿಫಲವಾಗಿದೆ: ಯಾವ ಪದರ?

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

ಸಂದೇಶವು ಒಂದು ಪದರವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಉಪಯುಕ್ತ ಕೆಲಸವೆಂದರೆ ಯಾವುದೇ ಸಾಮಗ್ರಿಯನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಯಾವುದು ಎಂದು ನಿರ್ಧರಿಸುವುದು. ಅಭ್ಯರ್ಥಿಗಳನ್ನು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಹೋಲಿಸುವುದು ವ್ಯತ್ಯಾಸವನ್ನು ನೋಡುವ ಅತ್ಯಂತ ವೇಗದ ದಾರಿ.

ಒಂದು ಪದವನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಎರಡು ವೈಫಲ್ಯಗಳು

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

ಈ ವ್ಯತ್ಯಾಸವು ದುರಸ್ತಿಯನ್ನು ಬದಲಿಸುತ್ತದೆ. ಒಂದಕ್ಕೆ ಚಾನೆಲ್ ಸೆಟ್ಟಿಂಗ್ಗಳ ಹೊಂದಾಣಿಕೆ ಬೇಕು, ಇನ್ನೊಂದಕ್ಕೆ ಖಾತೆಯ ಸ್ಥಿತಿ, ಮತ್ತು ಮೂರನೆಯದಕ್ಕೆ ತಲುಪಿದ ಶ್ರೋತೃಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದ ಪ್ರೊಫೈಲ್.

ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆ ನಿಜವಾಗಿ ಏನನ್ನು ಲೋಡ್ ಮಾಡಿತು ಎಂದು ಹೋಲಿಸಿ

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

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

ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಅನ್ನು ಡೇಟಾ ಚಾನೆಲ್ನೊಂದಿಗೆ ಹೋಲಿಸಿ

ಎರಡು ಕಾರ್ಯವಿಧಾನಗಳು ಸಂಪರ್ಕದ ಬೇರೆ ಬೇರೆ ಭಾಗಗಳನ್ನು ದೃಢೀಕರಿಸುತ್ತವೆ ಮತ್ತು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂರಚಿಸಲ್ಪಡುತ್ತವೆ, ಎಂದು 2.6 ಆಯ್ಕೆ ಉಲ್ಲೇಖ ವಿವರಿಸುತ್ತದೆ. tls-auth ನಿಯಂತ್ರಣ-ಚಾನೆಲ್ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ HMAC ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಎರಡು ಸಹವರ್ತಿಗಳಲ್ಲಿ ವಿರುದ್ಧವಾಗಿರಬೇಕಾದ ದಿಕ್ಕು-ಆರ್ಗ್ಯುಮೆಂಟ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ tls-crypt ಬದಲಿಗೆ ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಅನ್ನು ಹಂಚಿದ ಕೀಯಿಂದ ರಕ್ಷಿಸುತ್ತದೆ. ಎರಡೂ ಡೇಟಾ ಚಾನೆಲ್ನ ಸ್ವಂತ ಸಮಗ್ರತಾ ಪರಿಶೀಲನೆ ಅಲ್ಲ. AEAD ಡೇಟಾ ಸೈಫರ್ನೊಂದಿಗೆ ಆ ಪರಿಶೀಲನೆ ಸೈಫರ್ನಲ್ಲೇ ಅಂತರ್ಗತವಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ auth ಪ್ರತ್ಯೇಕ ಡೈಜೆಸ್ಟ್ ಅನ್ನು AEAD ಅಲ್ಲದ ಸೈಫರ್ನಂತೆ ಬಳಸಲಾಗುವುದಿಲ್ಲ.

ಅಂದರೆ, ಕೆಲಸ ಮಾಡುತ್ತಿರುವ AEAD ಅಲ್ಲದ ನಿಯೋಜನೆಯಿಂದ ನಕಲಿಸಿದ auth ಸಾಲು AEAD ನಿಯೋಜನೆಯಲ್ಲಿ ಅಪ್ರಸ್ತುತವಾಗಬಹುದು, ಮತ್ತು AEAD ನಿಯೋಜನೆ ನಿಯಂತ್ರಣ ಚಾನೆಲ್ನಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು, ಒಂದು ವೇಳೆ tls-auth ಕೀ ಅಥವಾ ಅದರ ದಿಕ್ಕು ತಪ್ಪಾಗಿದ್ದರೆ. ಪ್ರತಿ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸಹವರ್ತಿಯೊಂದಿಗೆ ಹೋಲಿಸಿ, ನೆನಪಿನಲ್ಲಿರುವ ಸಂರಚನೆಯೊಂದಿಗೆ ಅಲ್ಲ.

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

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

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಮೊದಲ ಸಂಬಂಧಿತ ಘಟನೆಯನ್ನು ಓದಿ, ನಂತರ ಅದು ಹೆಸರಿಸುವ ಅಸಂಗತಿಯನ್ನು ಮಾತ್ರ ಬದಲಿಸಿ.

ಮುಂದಿನ ಪ್ರಯತ್ನವು ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಲಾಗಿನ್ ದೋಷದವರೆಗೆ ಮುಂದುವರಿದರೆ, ಅದು ಹಿನ್ನಡೆಯಲ್ಲ, ಪ್ರಗತಿ: ಪ್ಯಾಕೆಟ್ ಪದರ ಈಗ ಒಪ್ಪುತ್ತದೆ ಮತ್ತು ಸಂಪರ್ಕ ಮುಂದೆ ಸಾಗಿದೆ. ಬದಲಾವಣೆಯನ್ನು ಉಂಟುಮಾಡಿದ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ದಾಖಲಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಒಗಟಿನ ಬದಲು ವಿವರಣೆಯನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯಲಿ.