VPN ಖಾಸಗಿ ಕೀಲಿಯ ಮೇಲಿನ ಪಾಸ್ಫ್ರೇಸ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ರಕ್ಷಿಸುತ್ತದೆ

VPN ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭವಾದಾಗ ಕಾಣುವ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ತಪ್ಪಾಗಿ ಓದುವುದು ಸುಲಭ. ಅದು VPN ಖಾತೆಯ ಪಾಸ್ವರ್ಡ್ ಅಲ್ಲ, ಟನೆಲ್ನ ಪಾಸ್ವರ್ಡ್ ಅಲ್ಲ, ಮತ್ತು ಅದನ್ನು ನಮೂದಿಸುವುದು ಸಂಪರ್ಕ ಸುರಕ್ಷಿತವೆಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಅದು ಖಾಸಗಿ ಕೀಲಿಯ ಒಂದು ಸಂಗ್ರಹಿತ ನಿರೂಪಣೆಯನ್ನು ಅನ್ಲಾಕ್ ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ಕ್ಲೈಂಟ್ ಕೀಲಿ ವಸ್ತುವನ್ನು ಓದಿ ದೃಢೀಕರಣಕ್ಕೆ ಬಳಸಬಹುದು. ಅದರ ನಂತರ ಏನಾಗುತ್ತದೆಯೋ ಅದು ಬೇರೆ ಪ್ರಶ್ನೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಉತ್ತರ ಅಂಚುಗಳಲ್ಲಿ ತಪ್ಪಾಗುತ್ತದೆ: ಪಾಸ್ಫ್ರೇಸ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಟನೆಲ್ ಅನ್ನು ರಕ್ಷಿಸುತ್ತದೆ ಅಥವಾ ಅದನ್ನು ಬದಲಿಸಿದರೆ ಈಗಾಗಲೇ ಸೋರಿಕೆಯಾದ ಕೀಲಿಯ ಪ್ರತಿ ರದ್ದಾಗುತ್ತದೆ ಎಂದು ಜನರು ಭಾವಿಸುತ್ತಾರೆ. ಎರಡೂ ಊಹೆಗಳು ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಎರಡೂ ಸೋರಿಕೆಯಾದ ರುಜುವಾತು ಬಯಲಾಗಿ ಉಳಿಯುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಆದರೆ ನಿರ್ವಾಹಕರು ಅದನ್ನು ನಿಭಾಯಿಸಲಾಗಿದೆ ಎಂದು ನಂಬುತ್ತಾರೆ.

ಒಂದು ಸಂವಾದ, ಹಲವು ವಿಭಿನ್ನ ರಹಸ್ಯಗಳು

ಖಾಸಗಿ ಕೀಲಿಯ ಪಾಸ್ಫ್ರೇಸ್ ಫೈಲ್ ಅನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ. ಖಾತೆ ಪಾಸ್ವರ್ಡ್ ನಿಮ್ಮನ್ನು ಸೇವೆಗೆ ದೃಢೀಕರಿಸುತ್ತದೆ. PKCS#12 ಆಮದು ಪಾಸ್ವರ್ಡ್ ಕೀಲಿ ಮತ್ತು ಅದರ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಹೊಂದಿರುವ ಬಂಡಲ್ ಅನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದು ಕೀಲಿಯ ಸ್ವಂತ ಪಾಸ್ಫ್ರೇಸ್ನಂತೆಯೇ ಅದೇ ಸ್ಟ್ರಿಂಗ್ ಆಗಿರಬೇಕಿಲ್ಲ. ಈ ಪ್ರಾಂಪ್ಟ್ಗಳು ಬಹುತೇಕ ಒಂದೇ ರೀತಿ ಕಾಣಬಹುದು, ಮತ್ತು ಯಾವ ರಹಸ್ಯ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಊಹಿಸುವುದು ಕೀಲಿಗಳು ತಪ್ಪು ಕ್ಷೇತ್ರಕ್ಕೆ ಅಂಟಿಕೊಳ್ಳುವ ದಾರಿ.

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

ಡಿಸ್ಕ್ನಲ್ಲಿನ ಎನ್ಕ್ರಿಪ್ಷನ್ ಏನನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ

ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ PEM ಕೀಲಿ ಎರಡು ರೂಪಗಳಲ್ಲಿ ಬರುತ್ತದೆ, ಮತ್ತು ಶೀರ್ಷಿಕೆ ನಿಮ್ಮಲ್ಲಿ ಯಾವುದು ಇದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಆಧುನಿಕ PKCS#8 ರೂಪ -----BEGIN ENCRYPTED PRIVATE KEY----- ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ; ಹಳೆಯ PEM ರೂಪ, ಹಳೆಯ OpenVPN ಸೆಟ್ಟಿಂಗ್ಗಳಲ್ಲಿ ಇನ್ನೂ ಸಾಮಾನ್ಯ, -----BEGIN RSA PRIVATE KEY----- ನಿಂದ ಪ್ರಾರಂಭವಾಗಿ ಅದರ ಕೆಳಗೆ Proc-Type: 4,ENCRYPTED ಮತ್ತು DEK-Info ಸಾಲನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಫೈಲ್ ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ನಿಮ್ಮ ಪಾಸ್ಫ್ರೇಸ್ನಿಂದ ಪಡೆದ ಕೀಲಿಯ ಅಡಿಯಲ್ಲಿ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿ ಇಡುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ದಿಷ್ಟ ಪುನರಾವರ್ತನೆ ಸಂಖ್ಯೆ ಅಥವಾ ಕೆಲಸದ ಅಂಶವನ್ನು ಹೊಂದಿರುವ ಪಾಸ್ವರ್ಡ್-ಆಧಾರಿತ KDF ಮೂಲಕ. OpenSSL pkey ದಾಖಲೆ ಸ್ವರೂಪಗಳನ್ನು ಮತ್ತು ಓದುವಾಗ ಅನ್ವಯವಾಗುವ ಪಾಸ್ಫ್ರೇಸ್ ಆಯ್ಕೆಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.

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

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 ಶೀರ್ಷಿಕೆಯನ್ನು ಮತ್ತು ಹಳೆಯ ಫೈಲ್ನಲ್ಲಿ ಎನ್ಕ್ರಿಪ್ಷನ್ ಸಾಬೀತುಪಡಿಸುವ Proc-Type ಮತ್ತು DEK-Info ಸಾಲುಗಳನ್ನು ತೋರಿಸುತ್ತದೆ; ಒಂದೇ ಸಾಲು ಯಾವ ದಿಕ್ಕಿನಲ್ಲೂ ಸಾಕ್ಷ್ಯವಲ್ಲ. pkey ಸಾಲು ಪಾಸ್ಫ್ರೇಸ್ ಕೇಳುತ್ತದೆ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಅರ್ಧವನ್ನು ಮಾತ್ರ ಮುದ್ರಿಸುತ್ತದೆ, ಇದು ಫೈಲ್ ಮತ್ತು ಪಾಸ್ಫ್ರೇಸ್ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂದು ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ಬಯಲು ಮಾಡದೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಆ ಪರಿಶೀಲನೆಗೆ -text ಬಳಸಬೇಡಿ: ಅದು ಖಾಸಗಿ ಘಟಕಗಳು, privateExponent, prime1, prime2 ಮತ್ತು ಉಳಿದವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಔಟ್ಪುಟ್ ಅನ್ನು ಎಂದಿಗೂ ಎಲ್ಲಿಯೂ ಅಂಟಿಸಬಾರದು, ಟಿಕೆಟ್ನಲ್ಲಿ, ಚಾಟ್ನಲ್ಲಿ ಅಥವಾ ಲಾಗ್ನಲ್ಲಿ ಅಲ್ಲ. PKCS#12 ಆದೇಶವು ಬಂಡಲ್ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ MAC ಅಥವಾ ಎನ್ಕ್ರಿಪ್ಷನ್ ಪಾಸ್ವರ್ಡ್ ಇದೆಯೇ ಎಂದೂ ಹೇಳುತ್ತದೆ, ಅದನ್ನು ಸಹೋದ್ಯೋಗಿಗೆ ನೀಡುವ ಮೊದಲು ತಿಳಿಯುವುದು ಒಳ್ಳೆಯದು.

ಕೀಲಿ ಲೋಡ್ ಆದ ನಂತರ ಅದು ಏನನ್ನು ರಕ್ಷಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ

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

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

ಪ್ರಾಂಪ್ಟ್ ಏಕೆ ಮತ್ತೆ ಮತ್ತೆ ಬರುತ್ತದೆ

ಪ್ರತಿ ಮರುಸಂಪರ್ಕದಲ್ಲೂ ಮತ್ತೆ ಕೇಳುವ ಕ್ಲೈಂಟ್ ಅಗತ್ಯವಾಗಿ ಮುರಿದಿಲ್ಲ. ಕೆಲವು ಕ್ಲೈಂಟ್ಗಳು ಸೆಷನ್ಗಾಗಿ ಪಾಸ್ಫ್ರೇಸ್ ಅನ್ನು ಕ್ಯಾಶ್ ಮಾಡುತ್ತವೆ, ಕೆಲವು ಅದನ್ನು OS ಕೀಚೈನ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತವೆ, ಮತ್ತು ಕೆಲವನ್ನು ಅದನ್ನು ಒದಗಿಸುವ ಸಹಾಯಕಕ್ಕೆ ನಿರ್ದೇಶಿಸಬಹುದು, ಆದ್ದರಿಂದ ನೀವು ಪಡೆಯುವ ನಡವಳಿಕೆ ಕ್ಲೈಂಟ್ ಮತ್ತು ಅದರ ಸಂರಚನೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ, ಕೀಲಿ ಫೈಲ್ ಅನ್ನಲ್ಲ.

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

ನಷ್ಟ ಮತ್ತು ಬಹಿರಂಗತೆ ಒಂದೇ ರಿಪೇರಿ ಅಲ್ಲ

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

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