A mund të funksionojë një certifikatë RSA me dh none në OpenVPN?

Këtu është një konfigurim serveri që thotë dh none pranë një certifikate që thotë RSA, plus dyshimi i bezdisshëm se njëra prej tyre duhet të jetë e gabuar. Asgjë nuk është e gabuar. Certifikata nënshkruan dhe vërteton; shkëmbimi i çelësave vendos një sekret të përbashkët. Këto janë dy punë të ndryshme në të njëjtin handshake, dhe TLS lejon që një certifikatë RSA të vërtetojë një handshake që përdor një marrëveshje efemere mbi kurbë eliptike.

Konfuzioni zakonisht vjen me një udhëzues migrimi. Ai thotë ta zëvendësosh skedarin e parametrave DH me dh none, lexuesi vëren se certifikata nuk është certifikatë e kurbës eliptike, dhe të dy faktet trajtohen si kundërshtim.

Pse dy cilësimet duken të lidhura

Konfigurimi më i vjetër i OpenVPN kërkonte një skedar parametrash DH sepse Diffie-Hellman në fushë të fundme ka nevojë për parametra domeni për të cilët bien dakord të dyja palët. Direktiva dh tregonte atë skedar. Kur një vendosje kalon në ECDH, parametrat vijnë nga një kurbë e emërtuar në vend të kësaj, dhe skedari nuk nevojitet më, gjë që shpreh dh none.

Certifikatat janë një bosht i veçantë. Ato mbajnë një çelës publik dhe një nënshkrim që provojnë identitetin e serverit, dhe ai çelës mund të jetë RSA ose kurbë eliptike pavarësisht se si bihet dakord për çelësin e sesionit. Një handshake që përdor ECDHE për marrëveshjen e çelësit dhe RSA për vërtetimin është i zakonshëm dhe i vendosur gjerësisht.

Emërtimi e përkeqëson mbivendosjen. Kurba eliptike shfaqet si në emrat e suitave ECDHE ashtu edhe ECDSA, prandaj është e lehtë të supozohet se çdo lidhje që përmend një kurbë duhet të përfshijë një certifikatë kurbe. Nuk është kështu.

Si të lexohet saktë një emër suite TLS 1.2

Merrni ECDHE-RSA-AES256-GCM-SHA384. Tokeni i parë është familja e shkëmbimit të çelësave: Diffie-Hellman efemer mbi kurbë eliptike. I dyti është familja e vërtetimit: RSA. Pjesa tjetër përshkruan mbrojtjen e regjistrave dhe hash-in e përdorur në handshake.

Suita ECDHE-ECDSA përdor të njëjtën familje shkëmbimi çelësash me një metodë tjetër vërtetimi, prandaj kërkon një certifikatë kurbe eliptike. Suita DHE-RSA përdor Diffie-Hellman efemer në fushë të fundme me vërtetim RSA, dhe ajo vërtet kërkon parametra DH.

Lexoni emrin e suitës nga e majta në të djathtë dhe caktoni secilën pjesë në punën e saj. Pasi tokenat ndahen, pyetja ndryshon nga «a përputhet certifikata ime me dh none» në «a lejon serveri im një suitë shkëmbimi çelësash e të cilës nuk kërkon skedar DH».

Çfarë çaktivizon në të vërtetë dh none

dh none i thotë serverit të mos ngarkojë një skedar parametrash DH në fushë të fundme. Ai nuk çaktivizon vërtetimin, validimin e certifikatave apo vetë TLS-in. Kërkon megjithatë që shkëmbimi i çelësave i rënë dakord të mos ketë nevojë për ato parametra, gjë që në praktikë do të thotë një suitë ECDHE ose një handshake TLS 1.3.

Nga ky kërkesë vjen prishja. Nëse politika e shifrave TLS e serverit është e kufizuar në suitat DHE, ose një klient ofron vetëm ato, heqja e skedarit të parametrave nuk lë asnjë metodë të përdorshme shkëmbimi çelësash dhe handshake dështon. Gabimi zakonisht shfaqet gjatë handshake-ut të kanalit të kontrollit, përpara çdo vërtetimi përdoruesi. Lexoni listën e shifrave përpara se të fajësoni skedarin që mungon.

Në anën e kurbës eliptike, kurbën e zgjedh konfigurimi TLS i serverit, dhe OpenVPN ofron një opsion për ta zgjedhur në degët më të vjetra. TLS 1.3 merret me negociatën e grupit brenda protokollit dhe nuk e konsulton fare skedarin DH.

dh none nuk është në vetvete një ulje sigurie. Fuqia e shkëmbimit varet atëherë nga kurba dhe suita që negociohen në të vërtetë, prandaj hapi tjetër është të shihni çfarë zgjodhën palët dhe jo skedarin që mungon.

Konfirmimi i negociatës para redaktimit

Rritni nivelin e detajeve të serverit dhe klientit dhe lexoni rreshtin e kanalit të kontrollit që OpenVPN shtyp pas një lidhjeje. Ai emërton versionin e TLS dhe shifrën e negociuar, dhe raporton llojin e çelësit të certifikatës së palës tjetër. Ai rresht i vetëm i përgjigjet pyetjes që skedari i konfigurimit vetëm e lë të nënkuptojë.

Nëse tregon TLS 1.2 me një suitë ECDHE-RSA dhe një certifikatë RSA, kombinimi është saktësisht ai që pret dh none, dhe nuk ka asgjë për të rregulluar. Nëse tregon një suitë DHE ose një dështim handshake pa shifër të përbashkët, rregullimi është në politikën e shifrave ose në aftësinë e klientit, jo në certifikatë.

Testoni klientin më të vjetër që synoni të mbështesni, sepse një klient aktual mund të negociojë TLS 1.3 ndërsa një më i vjetër kufizohet në suitat TLS 1.2. Nëse klienti më i vjetër nuk ka mbivendosje, ose zgjeroni suitat e lejuara ose përmirësoni atë pikë fundore.

Mos e çaktivizoni verifikimin e certifikatave për të kapërcyer një dështim handshake. Dështimi po ju thotë se palët nuk arritën të bien dakord për një shkëmbim çelësash, dhe çaktivizimi i kontrollit heq garancinë e identitetit pa zgjidhur marrëveshjen.

Listë kontrolli: a është certifikata RSA, a lejohet një suitë ECDHE, a e tregon regjistri atë suitë, dhe a e negocion edhe klienti më i vjetër i mbështetur? Nëse të katër janë po, dh none po bën punën e vet.