TLS-ĉifra eraro en OpenVPN: unue komparu ambaŭ flankojn

Eraro pri neniu komuna ĉifro sonas kiel unu agordo ŝanĝenda, kaj la agordo, kiun plej multaj homoj ŝanĝas, estas la malĝusta. OpenVPN tenas apartajn politikojn por la kontrolkanalo, kiu faras la TLS-manpremon, kaj por la datenkanalo, kiu portas pakojn ene de la tunelo, kaj la eraro nomas la unuan, dum homoj redaktas la duan. Kompari tion, kion permesas ĉiu flanko, en la ĝusta ordo, ŝanĝas la konjektadon en du aŭ tri decidojn: versio, poste listo de suitoj, poste legitimiloj.

Se vi eraras pri tiu ordo, vi povas pasigi horon aldonante AES-nomon al listo, kiu neniam estis konsultita.

Du ĉifraj listoj, kaj nur unu rompas la manpremon

La kontrolkanalo intertraktas TLS-sesion, kaj ĝia politiko estas skribata per tls-cipher por TLS 1.2 kaj tls-ciphersuites por TLS 1.3. La datenkanalo estas agordata aparte per data-ciphers, kie malkongruo produktas konekton, kiu establiĝas kaj poste ne povas trapasi trafikon. Ambaŭ produktas erarojn, kiuj mencias ĉifrojn, kaj tial ili konfuziĝas. Manpremo, kiu neniam finiĝas, montras al la kontrolkanalo, dum establita tunelo, kiu faligas pakojn, montras al la datenkanalo.

Legu la tutan mesaĝon anstataŭ la unuan linion. Malkongruo de versioj, mankanta suito, subskriba algoritmo de atestilo, kiun la flanko rifuzas, kaj malsukceso de kontrolo de gastigantnomo ĉiuj finiĝas per TLS-eraro, kaj nur unu el ili temas pri via listo de suitoj. Apartigi tiujn kategoriojn estas la pli granda parto de la diagnozo.

Komparu versiojn antaŭ ol kompari suitojn

Flanko limigita al TLS 1.2 kaj flanko, kiu postulas 1.3, dividas neniun version, kaj neniu ĉifra ĉeno pontas tion. Notu tls-version-min kaj tls-version-max ambaŭflanke, aŭ la defaŭltojn de la uzataj konstruoj, ĉar la OpenSSL-politiko de distribuaĵo povas levi la minimumon sen ke iu ajn OpenVPN-opcio tion diru. Se unu flanko estas aparato aŭ triaparta kliento, ĝia fenestro estas tio, kion permesas ĝia firmvaro. Nur kiam la fenestroj interkovriĝas, komparo de suitoj iel signifas.

Tiuj notoj ankaŭ nomu la efektivajn binaraĵojn. Komandlinia openvpn sur via tekkomputilo ne nepre estas la kliento, kiu pritraktas importitan profilon.

Listoj por TLS 1.2 kaj TLS 1.3 ne miksiĝas

Nomoj de suitoj por TLS 1.2 aspektas kiel ECDHE-RSA-AES256-GCM-SHA384 kaj apartenas al tls-cipher, kiu akceptas OpenSSL-ĉifran ĉenon. Suitoj de TLS 1.3 nomiĝas kiel TLS_AES_256_GCM_SHA384 kaj apartenas al tls-ciphersuites; aldoni unu al la 1.2-ĉeno ne agordas la 1.3-liston, kaj la analizilo povas akcepti la tekston sen iam ajn kongruigi ĝin. Filtrilo, kiu estas ĝusta por unu versio, diras nenion pri la alia. Notu, por kiu versio ĉiu listo estas destinita.

openvpn --show-tls presas tion, kion subtenas la loka konstruo, kaj tio estas inventaro, ne promeso: la fora flanko eble ne permesas tiujn suitojn, kaj la aktiva profilo eble ne ebligas ilin. Uzu ĝin por ekskludi konstruon, kiu entute ne povas proponi sueton, poste komparu la agorditajn listojn.

Pruvu la intertraktadon sur freŝa konekto

Sukcesa manpremo estas la sola pruvo, kiu valoras, kaj ĝi devas veni de la vera kliento kun la vera profilo. Pliigu la detalecon de la servilo, konektu unufoje, kaj legu el la protokolo la intertraktitan protokolversion kaj sueton anstataŭ supozi, ke la unue ofertita valoro venkis. Poste aparte konfirmu la datenkanalon per trafiko tra la tunelo, ĉar funkcianta manpremo kaj malsukcesanta datenkanalo estas malsamaj riparoj. Ripetu post iu ajn agorda ŝanĝo, ĉar malnova klienta profilo estas ofta falsa negativo.

Se ne ekzistas aprobita komuna agordo, la respondo estas ĝisdatigo aŭ migra plano, ne malfortigita politiko. Malaltigi la valoron de tls-version-min, malŝalti la kontrolon aŭ ebligi ĉiun malnovan sueton forigas la rifuzon sen plenumi la sekurecan postulon, kiu ĝin kaŭzis.

Notu la intertraktitan version, la sueton kaj la datenan ĉifron en la ŝanĝbileto. La sekva persono, kiu renkontos TLS-eraron, komencos de tiu noto anstataŭ de ĉifra ĉeno trovita en forumafiŝo.