OpenVPN tls-ciphersuites kontraŭ tls-version-min: kion ĉiu el ili devigas

Tri malsamaj faktoj kunfandiĝas en unu linion en la plej multaj diskutoj pri OpenVPN kaj TLS: kion povas fari via klienta konstruaĵo, kion permesas la profilo, kaj kion la seanco efektive interkonsentis. Mallonga listo de TLS 1.3-aroj respondas nur duone la mezan demandon, kaj ĝi diras nenion pri la malsupra limo de la protokola versio. Trapasu la subajn kontrolojn laŭ ordo kaj haltu ĉe la unua, kiu ne teniĝas, ĉar ĉiu posta kontrolo supozas, ke la antaŭaj estas solvitaj.

Kontrolu la konstruaĵon antaŭ ol legi ajnan liston

Konfigura direktivo ne povas aldoni protokolan subtenon al binara dosiero, kiu ne havas ĝin. Komencu per la versia rubando, kiu nomas la kompilitan kriptografian bibliotekon:

openvpn --version

Konstruaĵo 2.6 ligita al OpenSSL akceptas kaj tls-cipher kaj tls-ciphersuites. Konstruaĵo kun mbed TLS tute ne havas elekton de TLS 1.3-aroj, kaj la 2.6-manlibro markas tls-ciphersuites kiel OpenSSL-opcion. Se la servilo estas rekonstruita kun alia backend, la sama profilo povas ŝanĝi sian konduton sen ke eĉ unu linio de la agordo ŝanĝiĝu.

Dum vi estas ĉi tie, rulu openvpn --show-tls kaj konservu la eligon. Ĝi estas la inventaro, kun kiu vi poste komparos, kaj estas malmultekoste kapti ĝin antaŭ ol iu komencos redakti profilojn.

Skribu la rubandon kaj la liston en la ŝanĝbileton, ne en babilejan fenestron. Kiam du homoj disputas, ĉu kliento povus proponi aron post ses semajnoj, la kaptita eligo decidas tion en unu linio.

Tenu versiajn limojn aparte de ĉifro-listoj

En la 2.6-manlibro tiuj estas tri regiloj, ne unu:

• tls-cipher starigas la ĉifran politikon por TLS 1.2 kaj pli frue, kaj estas transdonata al la ĉifrolisto de OpenSSL;
• tls-ciphersuites elektas TLS 1.3-arojn;
• tls-version-min kaj tls-version-max limigas la protokolajn versiojn, kiujn la konekto rajtas uzi.

Do zorgeme pritondita listo de TLS 1.3-aroj pruvas nenion pri tio, ke pli malnova versio ankoraŭ estas permesata. Se la postulo estas «nur TLS 1.3», la versia malsupra limo portas ĝin, kaj la ara listo nur mallarĝigas la elektojn ene de tiu limo:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Tiu paro plenumas du taskojn. Forigi unu el la linioj lasas la alian devigi malpli, ol vi pensas, kaj ĝuste tiu fiasko estas la kialo, pro kiu ekzistas ĉi tiu tuta kontrolo.

La datena kanalo estas kvara regilo. data-ciphers interkonsentas la simetrian ĉifron ene de la tunelo, kaj ĝia rezulto diras nenion pri la TLS-versio de la rega kanalo. Vidi AES-256-GCM en la seanca resumo ne estas pruvo pri TLS 1.3 en iu ajn direkto.

Legu show-tls kiel lokan inventaron

--show-tls listigas la arojn subtenatajn de la kriptografia biblioteko, al kiu ĉi tiu binara dosiero estas ligita, laŭ prefera ordo. Ĝi ne estas raporto de la enirejo. La manlibro eksplicite diras, ke la listo venas de la loka biblioteko, kio signifas, ke tekkomputilo kun OpenSSL 3.x kaj enkursigilo kun pli malnova konstruaĵo presos malsamajn listojn dum ili parolas al la sama servilo.

Supozu, ke kliento subtenas arojn A, B kaj C kaj unu seanco elektas B. Tio establas nenion pri tio, ĉu la servilo permesas A aŭ C, nek pri tio, ĉu B estas ĝia sola permesata elekto. Tenu la tri vicojn aparte, kaj la plej multaj konfuzaj TLS-fadenoj solviĝos mem.

La inventaro tamen indas esti konservata. Kiam seanco malsukcesas, komparo de la biblioteka listo kun la profila listo montras, ĉu la kliento entute havis ŝancon proponi tion, kion la servilo volis. Ĝi ankaŭ montras, ĉu backend-ŝanĝo silente forigis TLS_CHACHA20_POLY1305_SHA256 el la provizo, de kiu dependas pli malnovaj klientoj — la speco de regreso, kiu montriĝas kiel manpleno da uzantoj, kiuj ne povas konektiĝi, dum ĉiuj aliaj rimarkas nenion.

Demandu la enirejon pri io, kion ĝi povas respondi

Se vi administras la servon, inspektu la efektivan agordon de la kuranta kazo anstataŭ dosieron sur la disko. OpenVPN eble estis startigita kun alia --config-vojo, eble tiras inkluzivojn, kaj eble ne estis restartigita post la redakto. La politiko de la kuranta demono estas tio, kion renkontas klientoj.

Se vi ne administras ĝin, demandu la operatoron pri subtenataj klientaj postuloj aŭ limigita akcepta testo. Rifuzita provo ne estas aŭtomate rifuzita aro: versia malsupra limo, kontroloj de atestila identeco kiel remote-cert-tls, aŭ malkongruo inter tls-auth kaj tls-crypt povas fini la interŝanĝon antaŭ ol ara elekto gravas. Legu la servilan eraron antaŭ ol ŝanĝi la klientan liston, ĉar «handshake failed» kovras kvar malsamajn kaŭzojn kaj nur unu el ili estas ĉifra malkongruo.

Ankaŭ direkti openssl s_client al la VPN-pordo ne reproduktas la demandon. La rega kanalo funkcias ene de la propra framado de OpenVPN, do kruda TLS-sondo testas alian protokolon sur pordo, kiu atendas ion alian. Ajna konkludo el ĝi temas pri la sondo, ne pri la tunelo.

Registru du rezultojn kaj tenu ilin aparte

Freŝa permesata seanco produktas regkanalan linion, kiu nomas la protokolan version kaj la elektitan ĉifron, kaj apartan datenkanalan linion, kiu nomas la tunelan ĉifron. Kaptu ambaŭ kun la klienta versio kaj la profila nomo, kaj notu, kiu servila kazo respondis:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Poste legu la du liniojn el tiu dosiero anstataŭ el la memoro. La paro estas la pruvo; ara nomo sola estas prefero, kaj la versia limo estas aparta aserto pri tio, kion la servilo rifuzas.

Rulu la kontrolojn en ĉi tiu ordo. Konfirmu la konstruaĵon kaj backend per --version. Kaptu --show-tls antaŭ ol ŝanĝi ion ajn. Deklaru la postulatan version malsupran limon aparte de la ara listo. Konfirmu la efektivan politikon de la kuranta kazo kun ĝia posedanto. Observu unu permesatan seancon kaj, se la plano permesas, unu rifuzitan provon de pli malnova versio. Registru la rezultojn de la rega kanalo kaj de la datena kanalo kiel apartajn konkludojn.

Se postulata kliento ne povas plenumi novan minimumon, faru tiun migradan aŭ esceptan decidon eksplicite anstataŭ silente malaltigi nerilatan akceptan regulon por igi la lanĉon aspekti finita.