OpenVPN EC vs ED: ಈ ಹೆಸರುಗಳು ಶಕ್ತಿಯ ಏಣಿ ಏಕೆ ಅಲ್ಲ
EC, ED, ECDHE ಮತ್ತು auth ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಏನನ್ನಾದರೂ ಹೋಲಿಸುವ ಅಥವಾ ಸಂಪಾದಿಸುವ ಮೊದಲು ಪ್ರತಿ ಹೆಸರು ಮಾಡುವ ಕೆಲಸದ ಪ್ರಕಾರ OpenVPN ಪ್ರೊಫೈಲ್ ಜೋಡಿಸಿ.
ಒಂದೇ ಪ್ರೊಫೈಲಿನಲ್ಲಿ ec, ed, ecdh, ecdsa, auth ಮತ್ತು TLS ಸೈಫರ್ ಪಟ್ಟಿಯನ್ನು ಅಕ್ಕಪಕ್ಕ ಇಡಿ, ಆಗ ಫೈಲ್ ಆರು ಸ್ಥಾನಗಳ ಶಕ್ತಿ ಡಯಲ್ನಂತೆ ಕಾಣಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಆದರೆ ಹಾಗಲ್ಲ. ಪ್ರತಿ ಹೆಸರು ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಭಿನ್ನವಾಗಿರುವ ಎರಡು ಪ್ರೊಫೈಲ್ಗಳು ಒಂದಕ್ಕೊಂದು ಹೆಚ್ಚು ಬಲಶಾಲಿ ಅಥವಾ ದುರ್ಬಲ ಎಂದೇನೂ ಅಲ್ಲ. ಹೆಸರನ್ನು ಅವು ಮಾಡುವ ಕೆಲಸದ ಪ್ರಕಾರ ಜೋಡಿಸಲು ಸುಮಾರು ಐದು ನಿಮಿಷ ಬೇಕು ಮತ್ತು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಸಂರಚನೆಯಲ್ಲಿ ಜನರು ಮಾಡುವ ಕೆಟ್ಟ ಬದಲಾವಣೆಗಳ ಬಹುಪಾಲನ್ನು ತಡೆಯುತ್ತದೆ.
ಕೆಳಗಿನ ಜೋಡಣೆ ಗೊಂದಲದಿಂದಲೇ ಪ್ರಾರಂಭವಾಗಿ, ನಂತರ ಹೊರಕ್ಕೆ, ನಿಮ್ಮ ಸಂಚಾರವನ್ನು ನಿಜವಾಗಿ ಯಾವುದು ರಕ್ಷಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಪ್ರೊಫೈಲಿನ ಭಾಗಗಳತ್ತ ಸಾಗುತ್ತದೆ. ಪ್ರತಿ ವಿಭಾಗವೂ ಸರದಿಯಲ್ಲಿ ಒಂದು ತಪ್ಪು ಓದನ್ನು ತೆಗೆದುಕೊಂಡು ಹೆಸರು ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ಬಂಧಿಸಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
ಎರಡು ಅಕ್ಷರ, ಎರಡು ಬೇರೆ ಪ್ರಶ್ನೆ
ಅತಿ ಹೆಚ್ಚು ಚರ್ಚೆ ಉಂಟುಮಾಡುವ ಜೋಡಿ EC ಮತ್ತು ED, ಮತ್ತು ಚರ್ಚೆ ಸಾಮಾನ್ಯವಾಗಿ ಅವು ಒಂದೇ ಪ್ರಶ್ನೆಗೆ ಪ್ರತಿಸ್ಪರ್ಧಿ ಉತ್ತರಗಳು ಎಂದು ಊಹಿಸುತ್ತದೆ. ಅವು ಒಂದೇ ಅಕ್ಷದ ಮೇಲೂ ಇಲ್ಲ. EC ಗಣಿತದ ಒಂದು ಕುಟುಂಬವನ್ನು ವಿವರಿಸುತ್ತದೆ: ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರರೇಖೆಯ ಗೂಢಲಿಪಿಶಾಸ್ತ್ರ, ಅಲ್ಲಿ ಭದ್ರತೆ ದೊಡ್ಡ ಸೀಮಿತ ಕ್ಷೇತ್ರದಲ್ಲಿ ಅಲ್ಲ, ವಕ್ರರೇಖೆಯ ಮೇಲಿನ ವಿವಿಕ್ತ ಲಘುಗಣಕದ ಕಠಿಣತೆಯಿಂದ ಬರುತ್ತದೆ.
ED ಆ ಕುಟುಂಬದ ಒಳಗಿನ ವಕ್ರರೇಖೆಯ ಆಕಾರವನ್ನು ವಿವರಿಸುತ್ತದೆ. Twisted Edwards ವಕ್ರರೇಖೆಗಳು ವೇಗ ಮತ್ತು ಹಲವು ಅನುಷ್ಠಾನ ದೋಷಗಳಿಗೆ ಪ್ರತಿರೋಧಕ್ಕಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ ನಿರೂಪಣೆ, ಮತ್ತು Ed25519 ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ಉದ್ದೇಶಿಸುವ ಹೆಸರು. ವಕ್ರರೇಖೆ ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರರೇಖೆಯ ಗೂಢಲಿಪಿಶಾಸ್ತ್ರದ ಪ್ರತಿಸ್ಪರ್ಧಿ ಅಲ್ಲ; ಅದು ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರರೇಖೆಯನ್ನು ಬರೆಯುವ ಒಂದು ದಾರಿ. ED ಅನ್ನು "ಹೊಸ, ಬಲಶಾಲಿ EC" ಎಂದು ಓದುವುದು ಮೊದಲ ತಪ್ಪು ತಿರುವು, ಮತ್ತು ಅದರ ನಂತರದ ಎಲ್ಲವೂ ಅದೇ ದಿಕ್ಕಿನಲ್ಲಿ ತಪ್ಪಾಗುವ ಸಾಧ್ಯತೆ ಇದೆ.
ಸಹಿ ಮಾಡುವುದು ಮತ್ತು ವಿನಿಮಯ ಮಾಡುವುದು ಬೇರೆ ಬೇರೆ ಕೆಲಸ
ಕುಟುಂಬದ ಪ್ರಶ್ನೆ ಬಗೆಹರಿದ ಮೇಲೆ, ಉಳಿದ ಹೆಸರುಗಳು ಎಂದಿಗೂ ಒಂದನ್ನೊಂದು ಬದಲಿಸದ ಎರಡು ಅಂಕಣಗಳಾಗಿ ಒಡೆಯುತ್ತವೆ. ಒಂದು ಅಂಕಣ ಸಹಿ ಮಾಡುತ್ತದೆ, ಇನ್ನೊಂದು ಹಂಚಿದ ರಹಸ್ಯಕ್ಕೆ ಒಪ್ಪುತ್ತದೆ.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA ಮತ್ತು ECDSA ಎರಡೂ ಸಹಿ ಮಾಡುತ್ತವೆ, ಆದರೆ ಅವು ಬೇರೆ ಬೇರೆ ಕೀಲಿ ಸ್ವರೂಪಗಳಿರುವ ಬೇರೆ ಬೇರೆ ಯೋಜನೆಗಳು, ಆದ್ದರಿಂದ ಒಂದಕ್ಕೆ ನೀಡಿದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಇನ್ನೊಂದರಂತೆ ಬಳಸಲಾಗದು. EdDSA ಕೆಲವೇ ವಕ್ರರೇಖೆಗಳ ಗುಂಪಿಗೆ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ; P-256 ಅವುಗಳಲ್ಲಿ ಒಂದಲ್ಲ, ಆದ್ದರಿಂದ P-256 ಪ್ರಮಾಣಪತ್ರವು ECDSA ಯಿಂದ ಪರಿಶೀಲನೆಯಾಗುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ Ed25519 ನಿಂದ ಅಲ್ಲ.
ವಿನಿಮಯ ಅಂಕಣದಲ್ಲಿ EdDH ಎಂಬ ಸಮಾನಾರ್ಥಕವಿಲ್ಲ. Curve25519 ಕೀಲಿಯ ಮೇಲಿನ ಕ್ಷಣಿಕ ಒಪ್ಪಂದ X25519, ಮತ್ತು ಅದು ನಿರ್ದಿಷ್ಟ ವಕ್ರರೇಖೆಯೊಂದಿಗೆ ECDH, P-256 ರಲ್ಲಿದ್ದಂತೆಯೇ. Ed25519 ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸಹಿ ಯೋಜನೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಆದರೂ ಎರಡು ವಕ್ರರೇಖೆಗಳು ಸಂಬಂಧಿತವಾಗಿರುವುದರಿಂದ ಹೆಸರು ವಿನಿಮಯಕ್ಕೂ ಸಡಿಲವಾಗಿ ಬಳಕೆಯಾಗುತ್ತದೆ: ಸಹಿಗೆ ಬಳಸುವ Edwards ರೂಪ ಮತ್ತು X25519 ಗೆ ಬಳಸುವ Montgomery ರೂಪ ಒಂದೇ ಆಧಾರ ಗುಂಪನ್ನು ವಿವರಿಸುತ್ತವೆ.
EC ಪ್ರೊಫೈಲಿನಲ್ಲಿ dh ಫೈಲ್ ಏಕೆ ಇಲ್ಲ
dh ಫೈಲ್ ಸೀಮಿತ ಕ್ಷೇತ್ರದ Diffie-Hellman ಗಾಗಿ ಮೊದಲೇ ರಚಿಸಿದ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಆ ನಿಯತಾಂಕಗಳು ಇರುವುದು ದೊಡ್ಡ ಅವಿಭಾಜ್ಯ ಸಂಖ್ಯೆ ಮತ್ತು ಜನಕ ಎಲ್ಲಿಂದಲಾದರೂ ಬರಬೇಕಾಗಿರುವುದರಿಂದ. ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರರೇಖೆಯ ವಿನಿಮಯಕ್ಕೆ ಅವು ಬೇಕಿಲ್ಲ: ಹೆಸರಿಸಿದ ವಕ್ರರೇಖೆಯೇ ನಿಯತಾಂಕ ಗುಂಪು, ಮತ್ತು ಎರಡೂ ಕಡೆ ಅದನ್ನು ಈಗಾಗಲೇ ತಿಳಿದಿವೆ. EC ಪ್ರೊಫೈಲ್ ಸೂಚನೆಯನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದಾದ ಸಂಪೂರ್ಣ ಕಾರಣ ಇದೇ.
ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಆಧುನಿಕ ಕಾಣುವ ಪ್ರೊಫೈಲಿನಲ್ಲಿ ಎರಡು ಸನ್ನಿವೇಶಗಳು ಇನ್ನೂ dh ಸಾಲನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಮೊದಲನೆಯದು ಸೀಮಿತ ಕ್ಷೇತ್ರದ ಗುಂಪುಗಳ ಬಗ್ಗೆ ನಿಜವಾಗಿ ಮಾತುಕತೆ ನಡೆಸುವ ಎರಡನೇ ಆಲಿಸುವವರು ಅಥವಾ ಹಳೆಯ ಸಹಯೋಗಿ. ಎರಡನೆಯದು RSA ಯುಗದ ಟೆಂಪ್ಲೇಟಿನಿಂದ ನಕಲಿಸಿ ಎಂದಿಗೂ ತೆಗೆಯದ ಉಳಿದ ಪಠ್ಯ. ವಿನಿಮಯಕ್ಕೆ ವಕ್ರರೇಖೆ ಹೆಸರಿಸಿ ಇನ್ನೂ 2048-ಬಿಟ್ dh ಫೈಲ್ ಲೋಡ್ ಮಾಡುವ ಪ್ರೊಫೈಲ್ ಹಾಗೆ ಮಾಡಿದ್ದರಿಂದ ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಲ್ಲ; ಅದು ಬಳಕೆಯಾಗದ ವಸ್ತುವನ್ನು ಹೊತ್ತಿದೆ.
TLS 1.3 ಕೀಲಿ ವಿನಿಮಯವನ್ನು ಹೆಸರಿನಿಂದ ತೆಗೆದುಹಾಕಿತು
TLS_AES_256_GCM_SHA384 ಮತ್ತು TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 ಹೋಲಿಸಿ, ಚಿಕ್ಕ ಹೆಸರು ಇಳಿಕೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಇದು ಮರುನಾಮಕರಣ, ಮತ್ತು ಕಾರಣ ರಚನಾತ್ಮಕ: TLS 1.3 ಸ್ಥಿರ RSA ಮತ್ತು ಸೀಮಿತ ಕ್ಷೇತ್ರದ Diffie-Hellman ಕೀಲಿ ವಿನಿಮಯವನ್ನು ತೆಗೆದುಹಾಕಿತು, ಆದ್ದರಿಂದ ಕ್ಷಣಿಕ ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರರೇಖೆಯ ವಿನಿಮಯವೇ ಉಳಿದ ಏಕೈಕ PSK ಅಲ್ಲದ ಆಯ್ಕೆ. ಪ್ರತಿ ಸೂಟ್ನಲ್ಲೂ ಅದನ್ನು ಹೆಸರಿಸುವುದು ಅದೇ ಸತ್ಯವನ್ನು ಡಜನ್ ಬಾರಿ ಪುನರಾವರ್ತಿಸುತ್ತಿತ್ತು.
ಪ್ರಮಾಣಪತ್ರದ ಪ್ರಕಾರ ಸಂಬಂಧಿತ ಕಾರಣದಿಂದ ಹೆಸರಿನಿಂದ ಮಾಯವಾಯಿತು. 1.3 ರಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರವು ಕೈಹಿಡಿತದ ಸಹಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಕೀಲಿ ಒಪ್ಪಂದವನ್ನಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ಇನ್ನು ಸೂಟ್ ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ. ಸಂರಚನೆಯಲ್ಲಿ 1.3 ಗೆ ಪ್ರತ್ಯೇಕ ಸೈಫರ್ ಪಟ್ಟಿ ಇರುವುದೂ ಅದೇ ಕಾರಣ: ಸೂಟ್ಗಳು ಮರುನಾಮಕರಣ ಮತ್ತು ಮರುಸಂಘಟನೆಯಾದವು, ದುರ್ಬಲಗೊಂಡಿಲ್ಲ.
ಒಂದು ಪರಿಣಾಮವನ್ನು ನೇರವಾಗಿ ಹೇಳುವುದು ಯೋಗ್ಯ. ECDHE ಕೀಲಿ ವಿನಿಮಯ ಕ್ರಮಾವಳಿ ಮತ್ತು ಎಂದಿಗೂ ಸೈಫರ್ ಅಲ್ಲ. "ದೀರ್ಘವೃತ್ತೀಯ" ಎಂದು ವಿವರಿಸಿದ ಸೂಟ್ ಎರಡು ಕಡೆ ಹಂಚಿದ ಕೀಲಿಗೆ ಹೇಗೆ ಬಂದವು ಎಂಬುದನ್ನು ಸ್ವಲ್ಪ ಹೇಳುತ್ತದೆ, ಮತ್ತು ನಂತರ ಪೇಲೋಡ್ ಅನ್ನು ಯಾವುದು ಗೂಢಲಿಪೀಕರಿಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ.
auth ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಪೇಲೋಡ್ ಅನ್ನಲ್ಲ
auth ಸೂಚನೆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ದೃಢೀಕರಿಸುವ HMAC ಸಾರಾಂಶವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದರ ಐತಿಹಾಸಿಕ ಪೂರ್ವನಿಯೋಜಿತ SHA1. AEAD ಅಲ್ಲದ ಡೇಟಾ ಸೈಫರ್ನೊಂದಿಗೆ OpenVPN ಗೂಢಲಿಪೀಕೃತ ಪಠ್ಯದ ಮೇಲೆ ಸಾರಾಂಶವನ್ನು ಲೆಕ್ಕಹಾಕಿ ಅದನ್ನು ಸೇರಿಸುತ್ತದೆ, ಇದು ಎನ್ಕ್ರಿಪ್ಟ್-ನಂತರ-MAC ವ್ಯವಸ್ಥೆ, ಪ್ಯಾಡಿಂಗ್ನೊಂದಿಗೆ ಕೈವಾಡ ಮಾಡುವುದನ್ನು ಅಪ್ರಾಯೋಗಿಕಗೊಳಿಸುತ್ತದೆ.
ಇಲ್ಲಿನ ಪುರಾಣ ಎಂದರೆ auth ಅನ್ನು SHA512 ಗೆ ಏರಿಸುವುದು ಸುರಂಗವನ್ನು ಗಟ್ಟಿಗೊಳಿಸುತ್ತದೆ ಎಂಬುದು. ಅದು ಗೂಢಲಿಪೀಕರಣದ ಶಕ್ತಿ ಹೆಚ್ಚಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸಮಾಲೋಚಿಸಿದ ಡೇಟಾ ಸೈಫರ್ AES-256-GCM ನಂತಹ AEAD ಮೋಡ್ ಆಗಿದ್ದರೆ, ಸಾರಾಂಶವು ಡೇಟಾ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಅನ್ವಯವಾಗುವುದಿಲ್ಲ. GCM ಟ್ಯಾಗ್ ಈಗಾಗಲೇ ಅವನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಮತ್ತು auth ಮೌಲ್ಯವು ನಿಯಂತ್ರಣ ಕಾಲುವೆಯ HMAC ಗೆ ಮತ್ತು ಇನ್ನೂ ಬಳಕೆಯಲ್ಲಿರುವ AEAD ಅಲ್ಲದ ಯಾವುದೇ ಸೈಫರ್ಗೆ ಉಳಿಯುತ್ತದೆ.
ಆದ್ದರಿಂದ ಸೂಚನೆ ಮುಖ್ಯ, ಆದರೆ ಫೈಲಿನಲ್ಲಿನ ಅದರ ಸ್ಥಾನ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಸಣ್ಣ ಜಾಗದಲ್ಲಿ ಮುಖ್ಯ. ಯಾವ ಸೈಫರ್ ನಿಜವಾಗಿ ಸಮಾಲೋಚಿಸಲ್ಪಟ್ಟಿತು ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಅನ್ವಯವಾಗುತ್ತದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ.
ಪ್ರೊಫೈಲ್ ಅನ್ನು ಅಂಕಣದಿಂದ ಓದಿ, ಶ್ರೇಣಿಯಿಂದ ಅಲ್ಲ
ಮೂರು ಪ್ರಶ್ನೆಗಳು ಪದರಗಳನ್ನು ಸ್ವಚ್ಛವಾಗಿ ಬೇರ್ಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸಮಾಲೋಚಿತ ಅಧಿವೇಶನದ ಬೇರೆ ಭಾಗ ಉತ್ತರಿಸುತ್ತದೆ. ಯಾವ ಸೈಫರ್ ಪೇಲೋಡ್ ಅನ್ನು ರಕ್ಷಿಸುತ್ತದೆ? ಯಾವ ಟ್ಯಾಗ್ ಅಥವಾ ಸಾರಾಂಶ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ಗೆ ಖಾತರಿ ನೀಡುತ್ತದೆ, ಮತ್ತು ಬಳಕೆಯಲ್ಲಿರುವ ಸೈಫರ್ಗೆ ಅದು ಬೇಕೇ? ಯಾರ ಪ್ರಮಾಣಪತ್ರ ಕೈಹಿಡಿತವನ್ನು ಮುಚ್ಚಿತು, ಮತ್ತು ನಿಯಂತ್ರಣ ಕಾಲುವೆ ಹೆಚ್ಚುವರಿಯಾಗಿ tls-auth ಅಥವಾ tls-crypt ನಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆಯೇ?
EC ಅಥವಾ ED ಲೇಬಲ್ನಲ್ಲಿ ಯಾವುದೂ ಆ ಮೂರರಲ್ಲಿ ಒಂದನ್ನೂ ನಿರ್ಧರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸೂಟ್ ಹೆಸರು ಒಂಟಿಯಾಗಿಯೂ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಸಮಾಲೋಚಿತ ಫಲಿತಾಂಶವೇ ಏಕೈಕ ಸಾಕ್ಷ್ಯ, ಆದ್ದರಿಂದ ಪದಕೋಶದಿಂದ ಶಕ್ತಿ ಊಹಿಸುವ ಬದಲು ಅದನ್ನು ಓದಿ:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logಮೊದಲ ಆಜ್ಞೆ ನಿಮ್ಮ ಪ್ರಮಾಣಪತ್ರ ನಿಜವಾಗಿ ಯಾವ ಸಹಿ ಯೋಜನೆಯನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ನೀವು ECDSA ಅಥವಾ Ed25519 ಚಲಾಯಿಸುತ್ತಿದ್ದೀರಾ ಎಂದು ತಿಳಿಯಲು ಇದೇ ಏಕೈಕ ನಂಬಲರ್ಹ ದಾರಿ. ಎರಡನೆಯದು ಕ್ಲೈಂಟ್ ಅಧಿವೇಶನಕ್ಕಾಗಿ ದಾಖಲಿಸಿದ ನಿಯಂತ್ರಣ ಕಾಲುವೆಯ ಸಾಲನ್ನು ತೋರಿಸುತ್ತದೆ, ಅದರಲ್ಲಿ TLS ಆವೃತ್ತಿ ಮತ್ತು ಅದು ನೆಲೆಗೊಂಡ ಸೂಟ್ ಸೇರಿವೆ. ಪ್ರೊಫೈಲ್ ಬದಲಾವಣೆಯನ್ನು ಆ ಎರಡು ಔಟ್ಪುಟ್ಗಳಲ್ಲಿ ಒಂದರಿಂದಲೂ ಸಮರ್ಥಿಸಲಾಗದಿದ್ದರೆ, ಅದು ಬಹುಶಃ ಗುಣದ್ದಲ್ಲ, ಹೆಸರಿನ ಬದಲಾವಣೆ.