OpenVPN: EC మరియు ED — ఈ పేర్లు ఎందుకు బలం మెట్టు కావు
EC, ED, ECDHE మరియు auth వేర్వేరు ప్రశ్నలకు సమాధానమిస్తాయి. ఏదైనా పోల్చడానికి లేదా మార్చడానికి ముందు ప్రతి పేరు చేసే పని ప్రకారం OpenVPN ప్రొఫైల్ను అమర్చండి.
ec, ed, ecdh, ecdsa, auth మరియు ఒక TLS సైఫర్ జాబితాను ఒకే ప్రొఫైల్లో పక్కపక్కన పెట్టండి, ఫైల్ ఆరు స్థానాల బలం డయల్లా కనిపించడం మొదలవుతుంది. అలా కాదు. ప్రతి పేరు వేరే ప్రశ్నకు సమాధానమిస్తుంది, వాటిలో ఒకదానిలో మాత్రమే భిన్నంగా ఉండే రెండు ప్రొఫైల్లు ఒకదానికొకటి బలంగా లేదా బలహీనంగా ఉండాల్సిన అవసరం లేదు. పేర్లను అవి చేసే పని ప్రకారం అమర్చడానికి దాదాపు ఐదు నిమిషాలు పడుతుంది, ఇది పని చేస్తున్న కాన్ఫిగరేషన్లో ప్రజలు చేసే చెడు మార్పులను ఎక్కువగా నిరోధిస్తుంది.
క్రింది అమరిక గందరగోళం నుండే మొదలై, మీ ట్రాఫిక్ను నిజంగా ఏది కాపాడుతుందో నిర్ణయించే ప్రొఫైల్ భాగాల వైపు బయటకు కదులుతుంది. ప్రతి విభాగం ఒక తప్పు పఠనాన్ని తీసుకొని, ఆ పేరు నిజంగా దేనికి జోడించబడిందో చూపిస్తుంది.
రెండు అక్షరాలు, రెండు వేర్వేరు ప్రశ్నలు
ఎక్కువ వాదనకు దారితీసే జోడీ EC మరియు ED, ఈ వాదన సాధారణంగా అవి ఒకే ప్రశ్నకు పోటీ సమాధానాలు అని ఊహిస్తుంది. అవి ఒకే అక్షం మీద కూడా లేవు. EC ఒక గణిత కుటుంబాన్ని వివరిస్తుంది: దీర్ఘవృత్త వక్ర మరుగుదల, ఇందులో భద్రత పెద్ద పరిమిత క్షేత్రంలో కాకుండా ఒక వక్రం మీద డిస్క్రీట్ లాగరిథమ్ కష్టం నుండి వస్తుంది.
ED ఆ కుటుంబం లోపల ఒక వక్ర ఆకృతిని వివరిస్తుంది. ట్విస్టెడ్ ఎడ్వర్డ్స్ వక్రాలు వేగం కోసం మరియు అనేక అమలు తప్పులకు నిరోధం కోసం ఎంచుకున్న ప్రాతినిధ్యం, మరియు ప్రజలు సాధారణంగా ఉద్దేశించే పేరు 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 ఖచ్చితంగా సంతకం పథకాన్ని సూచిస్తుంది, అయినా రెండు వక్రాలు సంబంధితమైనవి కాబట్టి ఆ పేరు మార్పిడికి కూడా సడలుగా వాడబడుతుంది: సంతకం కోసం వాడే ఎడ్వర్డ్స్ రూపం మరియు X25519 కోసం వాడే మాంట్గోమెరీ రూపం ఒకే అంతర్లీన సమూహాన్ని వివరిస్తాయి.
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 సంస్కరణ మరియు అది ఎంచుకున్న సూట్ ఉంటాయి. ఒక ప్రొఫైల్ మార్పును ఆ రెండు అవుట్పుట్లలో ఒకదానితో సమర్థించలేకపోతే, అది బహుశా ఒక లక్షణంలో కాదు, ఒక పేరులో చేసిన మార్పు.