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

ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ವಾಸ್ತವವಾಗಿ ಏನಿದೆ

tls-crypt-v2 ನ ಕ್ಲೈಂಟ್ ಅರ್ಧ ಭಾಗ ಕೀ ಮತ್ತು ಅದರ ಸುತ್ತಿದ ಪ್ರತಿ. ಕ್ಲೈಂಟ್ ನಿಯಂತ್ರಣ-ಚಾನೆಲ್ ರಕ್ಷಣೆಗೆ ಸಾಮಾನ್ಯ ಕೀ ಬಳಸುತ್ತದೆ ಮತ್ತು ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ ಸುತ್ತಿದ ಪ್ರತಿಯನ್ನು ಸರ್ವರ್ಗೆ ನೀಡುತ್ತದೆ, ಹಾಗಾಗಿ ಸರ್ವರ್ ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ ಸ್ಪಷ್ಟ ಪ್ರತಿ ಸಂಗ್ರಹಿಸದೆ ಅದೇ ಕೀಯನ್ನು ಮರುಪಡೆಯುತ್ತದೆ. ಸುತ್ತುವ ಕೀ ಆ ಮರುಪಡೆಯುವಿಕೆಯನ್ನು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಬದಿಗೆ ಮಾತ್ರ ಸೇರಿದೆ. ಕೆಳಗಿನ ಎಲ್ಲವೂ ಆ ಮೂರು ವಸ್ತುಗಳು ಎಲ್ಲಿವೆ ಎಂಬುದರಿಂದ ಬರುತ್ತದೆ.

ObjectWhere it livesWhat can open itWhat a leak costs
Server wrapping keyaccepting servers onlythe unwrap step inside the serverevery wrapped copy issued to that group becomes readable
Wrapped client keyinside the client profilethe server wrapping keyit names a client and exposes its metadata, but not the key inside
Client control keyinside the client profile, usable as-isthe client that owns itsomeone can open handshakes as that client until the server refuses the key

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

ಸುತ್ತಿದ ಪ್ರತಿ ಇಡೀ ಕಥೆ ಏಕೆ ಅಲ್ಲ

ಪ್ರೊಫೈಲ್ ಬಳಸಬಹುದಾದ ಕ್ಲೈಂಟ್ ಸಾಮಗ್ರಿಯನ್ನು ಅದರ ಸುತ್ತಿದ ಜೋಡಿಯೊಂದಿಗೆ ಒಯ್ಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್ಗಾಗಿ ಪ್ರತಿಯನ್ನು ರಕ್ಷಿಸುವುದು ಫೈಲ್ ರಕ್ಷಣೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. Blob ಪ್ರಸಾರಕ್ಕೆ ಸುರಕ್ಷಿತ ಮತ್ತು ಪ್ರಕಟಣೆಗೆ ಅಸುರಕ್ಷಿತ. ಅದರೊಳಗಿನ ಮೆಟಾಡೇಟಾ blob ಸ್ವೀಕರಿಸುವ ಯಾರಿಗೂ ಕಾಣುತ್ತದೆ, ಅದನ್ನು ಅಂಟಿಸಿದ ಟಿಕೆಟ್ ಅನ್ನು ನಂತರ ಓದುವವರೂ ಸೇರಿದಂತೆ.

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

ಕೈಕುಲುಕುವಿಕೆಯಲ್ಲಿ ಪರಿಶೀಲನಾ ಕೊಕ್ಕೆ ಎಲ್ಲಿದೆ

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

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

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

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

ಖಾತೆ, ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ನಿಯಂತ್ರಣ ಕೀ ಪ್ರತ್ಯೇಕವಾಗಿ ನಿಲ್ಲುತ್ತವೆ

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

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

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

ಪ್ರೊಫೈಲ್ ಬಿಡುಗಡೆ ಮತ್ತು ಹಿಂಪಡೆಯುವಿಕೆ

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

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

ಪ್ರೊಫೈಲ್ನಲ್ಲಿನ ಮೆಟಾಡೇಟಾ ಆ ನೀತಿಗೆ ಇನ್ಪುಟ್, ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ಈಗಾಗಲೇ ಇದೆ ಎಂಬ ಸಾಕ್ಷಿಯಲ್ಲ. OpenVPN 2.6 ವಿನ್ಯಾಸ ದಾಖಲೆ ವಸ್ತುಗಳನ್ನು ಮತ್ತು ಅವು ಎಳೆಯುವ ಗಡಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಆದರೆ ಅವನ್ನು ಜಾರಿಗೊಳಿಸುವುದು ನಿರ್ವಾಹಕನಲ್ಲಿಯೇ ಉಳಿಯುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು