Skedar DH apo çelës tls-auth? Të dallosh dy skedarë OpenVPN

Dy skedarë, dy direktiva dhe zakoni për t'i quajtur të dy sipas asaj që konfigurojnë. Kështu një dh.pem përfundon në një rresht tls-auth dhe klienti dështon me një mesazh për një format çelësi të papritur. Vendimi përpara jush nuk është cili skedar është më i fortë. Është cili rol i duhet vërtet vendosjes, dhe tre kushte e zgjidhin atë: çfarë shkëmbimi çelësash do të negociojë stack-u juaj TLS, nëse dëshironi fare vërtetim të kanalit të kontrollit, dhe nëse materiali duhet të mbetet sekret.

Përgjigjuni atyre me radhë dhe pyetja e skedarit përgjigjet vetë. Nëse i kaloni, emrat e direktivave fillojnë të duken të këmbyeshëm, dhe pikërisht nga kjo gjendje vjen gabimi.

Lexoni etiketën para emrit të skedarit

Rreshti i parë i skedarit jep më shumë informacion se emri, sepse emri është konventë njerëzore ndërsa etiketën e prodhon mjeti. Parametrat Diffie-Hellman mbajnë një etiketë PEM BEGIN DH PARAMETERS. Çelësi statik i OpenVPN është një strukturë krejt tjetër, me kokën dhe ngarkesën e vet heksadecimale.

Riemërtimi nuk konverton asgjë. Një skedar parametrash me emrin ta.key mbetet parametra, dhe një çelës statik me emrin dh.pem mbetet çelës statik; analizatori lexon përmbajtjen dhe refuzon mospërputhjen. Kontrolloni para se të redaktoni profilin:

head -n 1 dh.pem
head -n 1 ta.key

Tre kushte që vendosin cilin skedar ju nevojitet

Kushti i parë është shkëmbimi. Një shtrëngim duarsh Diffie-Hellman në fushë të fundme kërkon një grup, dhe direktiva dh është vendi ku serveri emërton parametrat për të. Një shtrëngim duarsh në kurbë eliptike nuk e kërkon fare atë skedar, sepse kurba është vetë bashkësia e parametrave. Nëse serveri juaj negocion vetëm grupe ECDHE, skedari DH është peshë e vdekur dhe jo forcë shtesë.

Kushti i dytë është vërtetimi i kanalit të kontrollit, një funksion i veçantë me materialin e vet. Skedari tls-auth është një çelës statik i përbashkët që të dy palët e mbajnë, i përdorur për të nënshkruar paketat e kanalit të kontrollit, që një palë e pavërtetuar të mos mund të përfundojë as shtrëngimin e duarve. Ekziston pavarësisht nëse përdorni DH në fushë të fundme dhe nuk ka asnjë lidhje me parametrat e grupit.

Kushti i tretë është sekreti dhe shpërndarja. Parametrat DH mund të publikohen pa e dobësuar sesionin, sepse vlerat sekrete krijohen për çdo shtrëngim duarsh dhe nuk i lënë kurrë palët. Një çelës statik nuk duhet publikuar: janë të njëjtat bajt në të dy skajet, nuk rrotullohet vetë, dhe kushdo që e mban mund të prodhojë nënshkrime të vlefshme të kanalit të kontrollit. Këto dy përgjigje çojnë në rregulla trajtimi krejt të ndryshme, dhe për këtë arsye njëri skedar mund të rrijë në një depo dhe tjetri jo.

Prodho materialin e duhur për çdo rol

Përdorni mjetin që prodhon formatin që pret direktiva, në vend që të konvertoni midis tyre. Për çelësin e përbashkët në OpenVPN 2.6, forma e tipizuar e gjeneratorit e deklaron qëllimin në mënyrë eksplicite.

openvpn --genkey tls-auth ta.key

Ai komandë krijon material të ri sekret; nuk riparon dhe nuk inspekton një çelës ekzistues, dhe ekzekutimi përsëri ju jep një çelës tjetër që palët e tjera nuk e kanë. Kopjoni skedarin që rezulton tek palët që kanë nevojë për të përmes një kanali që do të përdornit për çdo sekret të përbashkët, dhe mbani konventën e drejtimit konsistente: me tls-auth njëra anë përdor key-direction 0 dhe tjetra key-direction 1.

Parametrat DH, kur ju nevojiten, vijnë nga gjenerimi i parametrave dhe jo nga një gjenerator çelësash, dhe origjina e tyre ka rëndësi edhe kur rezultati është publik. Një grup i marrë nga një burim i panjohur nuk bëhet i besueshëm sepse është publik; ai ende duhet të jetë një grup për të cilin palët tuaja bien dakord dhe një që nuk dobësohet nga madhësia ose ndërtimi i tij.

Çfarë bën dh none dhe çfarë nuk bën

dh none është një direktivë e vërtetë me kuptim të ngushtë: asnjë skedar parametrash i fushës së fundme nuk do të ngarkohet, sepse shtrëngimi i duarve përdor Diffie-Hellman në kurbë eliptike. Nuk është shkurtim për «kapërce hapin DH» në kuptimin e dobësimit të diçkaje, dhe sigurisht nuk i thotë OpenVPN të pranojë një skedar tjetër si zëvendësues.

Dy gabime vijnë nga leximi i gabuar. I pari është të supozosh se dh none heq nevojën për tls-auth, ndërsa të dyja kontrollojnë gjëra të ndryshme. I dyti është të mbash një rresht dh të vjetëruar pranë një konfigurimi vetëm me kurbë dhe pastaj të pyesësh se cili skedar po përdor serveri në të vërtetë; nëse direktiva është e pranishme, skedari lexohet, dhe një rrugë e thyer atje dështon nisjen për një arsye pa lidhje me shkëmbimin që do të negociohet.

Nëse skedari i gabuar është vendosur tashmë

Rikthe sekretin e synuar nga pronari i profilit dhe mos prek verifikimin e certifikatës ndërsa e bën këtë. Dështimi është mospërputhje formati, jo dështim besimi, dhe çaktivizimi i verifikimit për të anashkaluar gabimin zëvendëson një problem nisjeje me një problem të heshtur.

Pastaj ndaj dy ngjarjet që njerëzit priren t'i bashkojnë. Publikimi i një skedari parametrash DH është pothuajse i pafajshëm, sepse parametrat ishin publikë nga projektimi. Ekspozimi i çelësit tls-auth është një ngjarje tjetër: çelësi vërteton paketat e kanalit të kontrollit për çdo palë që e mban, kështu që zëvendësimi duhet të koordinohet në të gjithë vendosjen dhe jo të zbatohet në një host të vetëm.

Një kontroll prej pesë minutash vendos në cilin rast jeni: lexoni rreshtin e parë të çdo skedari, konfirmoni direktivën që i referohet dhe konfirmoni se shpërndarja e skedarit përputhet me atë që kërkon materiali. Është punë më e vogël se rigjenerimi i një PKI funksionale, dhe ishte ajo që tre kushtet tregonin gjatë gjithë kohës.