OpenVPN ನಲ್ಲಿ dh none ಜೊತೆ RSA ಪ್ರಮಾಣಪತ್ರ ಕೆಲಸ ಮಾಡಬಹುದೇ?

ಇಲ್ಲಿ RSA ಎಂದು ಹೇಳುವ ಪ್ರಮಾಣಪತ್ರದ ಪಕ್ಕದಲ್ಲಿ dh none ಎಂದು ಹೇಳುವ ಸರ್ವರ್ ಸಂರಚನೆ ಇದೆ, ಜೊತೆಗೆ ಅವುಗಳಲ್ಲಿ ಒಂದು ಖಂಡಿತವಾಗಿ ತಪ್ಪಾಗಿರಬೇಕು ಎಂಬ ಕಾಡುವ ಸಂದೇಹ. ಯಾವುದೂ ತಪ್ಪಿಲ್ಲ. ಪ್ರಮಾಣಪತ್ರವು ಸಹಿ ಹಾಕುತ್ತದೆ ಮತ್ತು ದೃಢೀಕರಿಸುತ್ತದೆ; ಕೀಲಿ-ವಿನಿಮಯವು ಹಂಚಿಕೆಯ ರಹಸ್ಯವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಇವು ಒಂದೇ ಹ್ಯಾಂಡ್ಶೇಕ್ನಲ್ಲಿ ಎರಡು ವಿಭಿನ್ನ ಕೆಲಸಗಳು, ಮತ್ತು TLS RSA ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ತಾತ್ಕಾಲಿಕ ದೀರ್ಘವೃತ್ತೀಯ-ವಕ್ರ ಸಮ್ಮತಿಯನ್ನು ಬಳಸುವ ಹ್ಯಾಂಡ್ಶೇಕ್ ಅನ್ನು ದೃಢೀಕರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ಗೊಂದಲ ಸಾಮಾನ್ಯವಾಗಿ ವಲಸೆ ಮಾರ್ಗದರ್ಶಿಯೊಂದಿಗೆ ಬರುತ್ತದೆ. ಅದು DH ಪ್ಯಾರಾಮೀಟರ್ ಫೈಲ್ ಅನ್ನು dh none ನಿಂದ ಬದಲಾಯಿಸಲು ಹೇಳುತ್ತದೆ, ಓದುಗರು ಪ್ರಮಾಣಪತ್ರವು ದೀರ್ಘವೃತ್ತೀಯ-ವಕ್ರ ಪ್ರಮಾಣಪತ್ರವಲ್ಲ ಎಂದು ಗಮನಿಸುತ್ತಾರೆ, ಮತ್ತು ಎರಡೂ ಸಂಗತಿಗಳನ್ನು ವಿರೋಧಾಭಾಸವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಎರಡು ಸೆಟ್ಟಿಂಗ್ಗಳು ಸಂಬಂಧಿತವಾಗಿ ಕಾಣುವುದೇಕೆ

OpenVPN ನ ಹಳೆಯ ಸಂರಚನೆ DH ಪ್ಯಾರಾಮೀಟರ್ ಫೈಲ್ ಅನ್ನು ಕೇಳಿತು ಏಕೆಂದರೆ ಸೀಮಿತ-ಕ್ಷೇತ್ರ Diffie-Hellman ಗೆ ಎರಡೂ ಕಡೆ ಒಪ್ಪುವ ಡೊಮೇನ್ ಪ್ಯಾರಾಮೀಟರ್ಗಳು ಬೇಕು. dh ನಿರ್ದೇಶವು ಆ ಫೈಲ್ ಅನ್ನು ಸೂಚಿಸುತ್ತಿತ್ತು. ನಿಯೋಜನೆ ECDH ಗೆ ಹೋದಾಗ, ಪ್ಯಾರಾಮೀಟರ್ಗಳು ಬದಲಿಗೆ ಹೆಸರಿಸಿದ ವಕ್ರದಿಂದ ಬರುತ್ತವೆ, ಮತ್ತು ಫೈಲ್ ಇನ್ನು ಬೇಕಿಲ್ಲ, ಅದನ್ನೇ dh none ವ್ಯಕ್ತಪಡಿಸುತ್ತದೆ.

ಪ್ರಮಾಣಪತ್ರಗಳು ಪ್ರತ್ಯೇಕ ಅಕ್ಷ. ಅವು ಸಾರ್ವಜನಿಕ ಕೀಲಿ ಮತ್ತು ಸಹಿಯನ್ನು ಹೊತ್ತು ಸರ್ವರ್ನ ಗುರುತನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಆ ಕೀಲಿ ಸೆಷನ್ ಕೀಲಿ ಹೇಗೆ ಒಪ್ಪಿಗೆಯಾಗುತ್ತದೆ ಎಂಬುದರ ಹೊರತಾಗಿ RSA ಅಥವಾ ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರವಾಗಿರಬಹುದು. ಕೀಲಿ ಒಪ್ಪಂದಕ್ಕೆ ECDHE ಮತ್ತು ದೃಢೀಕರಣಕ್ಕೆ RSA ಬಳಸುವ ಹ್ಯಾಂಡ್ಶೇಕ್ ಸಾಮಾನ್ಯ ಮತ್ತು ವ್ಯಾಪಕವಾಗಿ ನಿಯೋಜಿಸಲಾಗಿದೆ.

ಹೆಸರಿಸುವಿಕೆ ಅತಿವ್ಯಾಪ್ತಿಯನ್ನು ಹದಗೆಡಿಸುತ್ತದೆ. ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರವು ECDHE ಮತ್ತು ECDSA ಎರಡೂ ಸೂಟ್ ಹೆಸರುಗಳಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ವಕ್ರವನ್ನು ಉಲ್ಲೇಖಿಸುವ ಯಾವುದೇ ಸಂಪರ್ಕದಲ್ಲಿ ವಕ್ರ ಪ್ರಮಾಣಪತ್ರವಿರಬೇಕು ಎಂದು ಊಹಿಸುವುದು ಸುಲಭ. ಹಾಗಿಲ್ಲ.

TLS 1.2 ಸೂಟ್ ಹೆಸರನ್ನು ಸರಿಯಾಗಿ ಓದುವುದು

ECDHE-RSA-AES256-GCM-SHA384 ತೆಗೆದುಕೊಳ್ಳಿ. ಮೊದಲ ಟೋಕನ್ ಕೀಲಿ-ವಿನಿಮಯ ಕುಟುಂಬ: ತಾತ್ಕಾಲಿಕ ದೀರ್ಘವೃತ್ತೀಯ-ವಕ್ರ Diffie-Hellman. ಎರಡನೆಯದು ದೃಢೀಕರಣ ಕುಟುಂಬ: RSA. ಉಳಿದದ್ದು ದಾಖಲೆ ರಕ್ಷಣೆ ಮತ್ತು ಹ್ಯಾಂಡ್ಶೇಕ್ನಲ್ಲಿ ಬಳಸುವ ಹ್ಯಾಶ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ.

ECDHE-ECDSA ಸೂಟ್ ಅದೇ ಕೀಲಿ-ವಿನಿಮಯ ಕುಟುಂಬವನ್ನು ಬೇರೆ ದೃಢೀಕರಣ ವಿಧಾನದೊಂದಿಗೆ ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದಕ್ಕೆ ದೀರ್ಘವೃತ್ತೀಯ-ವಕ್ರ ಪ್ರಮಾಣಪತ್ರ ಬೇಕು. DHE-RSA ಸೂಟ್ RSA ದೃಢೀಕರಣದೊಂದಿಗೆ ಸೀಮಿತ-ಕ್ಷೇತ್ರ ತಾತ್ಕಾಲಿಕ Diffie-Hellman ಬಳಸುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೆ ನಿಜವಾಗಿಯೂ DH ಪ್ಯಾರಾಮೀಟರ್ಗಳು ಬೇಕು.

ಸೂಟ್ ಹೆಸರನ್ನು ಎಡದಿಂದ ಬಲಕ್ಕೆ ಓದಿ ಮತ್ತು ಪ್ರತಿ ಭಾಗವನ್ನು ಅದರ ಕೆಲಸಕ್ಕೆ ನಿಗದಿಪಡಿಸಿ. ಟೋಕನ್ಗಳು ಬೇರ್ಪಟ್ಟ ನಂತರ, ಪ್ರಶ್ನೆ «ನನ್ನ ಪ್ರಮಾಣಪತ್ರ dh none ಗೆ ಹೊಂದುತ್ತದೆಯೇ» ಎಂಬುದರಿಂದ «ನನ್ನ ಸರ್ವರ್ DH ಫೈಲ್ ಬೇಕಿಲ್ಲದ ಕೀಲಿ-ವಿನಿಮಯವಿರುವ ಸೂಟ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆಯೇ» ಎಂಬುದಕ್ಕೆ ಬದಲಾಗುತ್ತದೆ.

dh none ನಿಜವಾಗಿ ಏನನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ

dh none ಸರ್ವರ್‌ಗೆ ಸೀಮಿತ-ಕ್ಷೇತ್ರ DH ಪ್ಯಾರಾಮೀಟರ್ ಫೈಲ್ ಲೋಡ್ ಮಾಡಬೇಡ ಎಂದು ಹೇಳುತ್ತದೆ. ಅದು ದೃಢೀಕರಣ, ಪ್ರಮಾಣಪತ್ರ ಮಾನ್ಯತೆ ಅಥವಾ TLS ಅನ್ನೇ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ. ಆದರೆ ಒಪ್ಪಿಗೆಯಾದ ಕೀಲಿ-ವಿನಿಮಯವು ಆ ಪ್ಯಾರಾಮೀಟರ್ಗಳ ಅಗತ್ಯವಿಲ್ಲದ್ದಾಗಿರಬೇಕು ಎಂದು ಒತ್ತಾಯಿಸುತ್ತದೆ, ಇದು ಪ್ರಾಯೋಗಿಕವಾಗಿ ECDHE ಸೂಟ್ ಅಥವಾ TLS 1.3 ಹ್ಯಾಂಡ್ಶೇಕ್ ಎಂದರ್ಥ.

ಈ ಅಗತ್ಯದಿಂದಲೇ ಒಡೆಯುವಿಕೆ ಬರುತ್ತದೆ. ಸರ್ವರ್ನ TLS ಸೈಫರ್ ನೀತಿ DHE ಸೂಟ್ಗಳಿಗೆ ಸೀಮಿತವಾಗಿದ್ದರೆ, ಅಥವಾ ಕ್ಲೈಂಟ್ ಅವುಗಳನ್ನೇ ನೀಡಿದರೆ, ಪ್ಯಾರಾಮೀಟರ್ ಫೈಲ್ ತೆಗೆದರೆ ಯಾವುದೇ ಬಳಸಬಹುದಾದ ಕೀಲಿ-ವಿನಿಮಯ ವಿಧಾನ ಉಳಿಯುವುದಿಲ್ಲ ಮತ್ತು ಹ್ಯಾಂಡ್ಶೇಕ್ ವಿಫಲವಾಗುತ್ತದೆ. ದೋಷ ಸಾಮಾನ್ಯವಾಗಿ ನಿಯಂತ್ರಣ-ಚಾನೆಲ್ ಹ್ಯಾಂಡ್ಶೇಕ್ ಸಮಯದಲ್ಲಿ, ಯಾವುದೇ ಬಳಕೆದಾರ ದೃಢೀಕರಣಕ್ಕೂ ಮೊದಲು ಕಾಣಿಸುತ್ತದೆ. ಕಾಣೆಯಾದ ಫೈಲ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಸೈಫರ್ ಪಟ್ಟಿ ಓದಿ.

ದೀರ್ಘವೃತ್ತೀಯ-ವಕ್ರದ ಬದಿಯಲ್ಲಿ, ವಕ್ರವನ್ನು ಸರ್ವರ್ನ TLS ಸಂರಚನೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು OpenVPN ಹಳೆಯ ಶಾಖೆಗಳಲ್ಲಿ ಅದನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಆಯ್ಕೆ ನೀಡುತ್ತದೆ. TLS 1.3 ಗುಂಪು ಮಾತುಕತೆಯನ್ನು ಪ್ರೋಟೋಕಾಲ್ ಒಳಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು DH ಫೈಲ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನೋಡುವುದಿಲ್ಲ.

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

ಸಂಪಾದನೆಗೆ ಮೊದಲು ಮಾತುಕತೆಯನ್ನು ದೃಢೀಕರಿಸುವುದು

ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ನ ವಿವರಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸಿ ಮತ್ತು ಸಂಪರ್ಕದ ನಂತರ OpenVPN ಮುದ್ರಿಸುವ ನಿಯಂತ್ರಣ-ಚಾನೆಲ್ ಸಾಲನ್ನು ಓದಿ. ಅದು TLS ಆವೃತ್ತಿ ಮತ್ತು ಒಪ್ಪಿಗೆಯಾದ ಸೈಫರ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಸಹಚರ ಪ್ರಮಾಣಪತ್ರದ ಕೀಲಿ ಪ್ರಕಾರವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಆ ಒಂದೇ ಸಾಲು ಸಂರಚನೆ ಫೈಲ್ ಕೇವಲ ಸೂಚಿಸುವ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.

ಅದು TLS 1.2 ಜೊತೆ ECDHE-RSA ಸೂಟ್ ಮತ್ತು RSA ಪ್ರಮಾಣಪತ್ರವನ್ನು ತೋರಿಸಿದರೆ, ಸಂಯೋಜನೆ ನಿಖರವಾಗಿ dh none ನಿರೀಕ್ಷಿಸುವಂತೆಯೇ ಇದೆ, ಮತ್ತು ಸರಿಪಡಿಸಲು ಏನೂ ಇಲ್ಲ. ಅದು DHE ಸೂಟ್ ಅಥವಾ ಸಾಮಾನ್ಯ ಸೈಫರ್ ಇಲ್ಲದ ಹ್ಯಾಂಡ್ಶೇಕ್ ವೈಫಲ್ಯವನ್ನು ತೋರಿಸಿದರೆ, ಪರಿಹಾರ ಸೈಫರ್ ನೀತಿ ಅಥವಾ ಕ್ಲೈಂಟ್ ಸಾಮರ್ಥ್ಯದಲ್ಲಿದೆ, ಪ್ರಮಾಣಪತ್ರದಲ್ಲಲ್ಲ.

ನೀವು ಬೆಂಬಲಿಸಲು ಉದ್ದೇಶಿಸಿರುವ ಅತ್ಯಂತ ಹಳೆಯ ಕ್ಲೈಂಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಪ್ರಸ್ತುತ ಕ್ಲೈಂಟ್ TLS 1.3 ಗೆ ಒಪ್ಪಬಹುದು ಆದರೆ ಹಳೆಯದು TLS 1.2 ಸೂಟ್ಗಳಿಗೆ ಸೀಮಿತವಾಗಿರುತ್ತದೆ. ಅತ್ಯಂತ ಹಳೆಯ ಕ್ಲೈಂಟ್ಗೆ ಯಾವುದೇ ಅತಿವ್ಯಾಪ್ತಿ ಇಲ್ಲದಿದ್ದರೆ, ಅನುಮತಿಸಿದ ಸೂಟ್ಗಳನ್ನು ವಿಸ್ತರಿಸಿ ಅಥವಾ ಆ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ನವೀಕರಿಸಿ.

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

ಪರಿಶೀಲನಾ ಪಟ್ಟಿ: ಪ್ರಮಾಣಪತ್ರ RSA ಆಗಿದೆಯೇ, ECDHE ಸೂಟ್ ಅನುಮತಿಸಲಾಗಿದೆಯೇ, ಲಾಗ್ ಆ ಸೂಟ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆಯೇ, ಮತ್ತು ಅತ್ಯಂತ ಹಳೆಯ ಬೆಂಬಲಿತ ಕ್ಲೈಂಟ್ ಕೂಡ ಅದಕ್ಕೆ ಒಪ್ಪುತ್ತದೆಯೇ? ನಾಲ್ಕೂ ಹೌದಾದರೆ, dh none ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ.