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 తన పని చేస్తోంది.