Maaari bang gumana ang RSA certificate sa dh none sa OpenVPN?

Narito ang isang configuration ng server na nagsasabing dh none sa tabi ng certificate na nagsasabing RSA, kasama ang nakakainis na hinala na ang isa sa kanila ay dapat mali. Walang mali. Ang certificate ay pumipirma at nagpapatunay; ang key exchange ay nagtatatag ng shared secret. Dalawang magkaibang trabaho ang mga ito sa iisang handshake, at pinapayagan ng TLS ang RSA certificate na i-authenticate ang handshake na gumagamit ng ephemeral elliptic-curve agreement.

Karaniwang dumarating ang kalituhan kasama ng migration guide. Sinasabi nitong palitan ang DH parameter file ng dh none, napapansin ng mambabasa na ang certificate ay hindi elliptic-curve certificate, at itinuturing ang dalawang katotohanan bilang kontradiksyon.

Bakit mukhang magkaugnay ang dalawang setting

Ang lumang configuration ng OpenVPN ay humihingi ng DH parameter file dahil ang finite-field Diffie-Hellman ay nangangailangan ng domain parameters na pinagkasunduan ng dalawang panig. Itinuro ng dh directive ang file na iyon. Kapag lumipat ang deployment sa ECDH, ang mga parameter ay nagmumula sa isang pinangalanang curve sa halip, at hindi na kailangan ang file, na ipinapahayag ng dh none.

Ang mga certificate ay hiwalay na axis. Nagdadala ang mga ito ng public key at signature na nagpapatunay ng pagkakakilanlan ng server, at ang key na iyon ay maaaring RSA o elliptic curve anuman ang paraan ng pagkasundo sa session key. Ang handshake na gumagamit ng ECDHE para sa key agreement at RSA para sa authentication ay karaniwan at malawakang naka-deploy.

Pinalala ng pagpapangalan ang overlap. Lumilitaw ang elliptic curve sa parehong ECDHE at ECDSA suite names, kaya madaling ipagpalagay na ang anumang koneksyon na nagbabanggit ng curve ay dapat may curve certificate. Hindi ganoon.

Paano basahin nang tama ang pangalan ng TLS 1.2 suite

Kunin ang ECDHE-RSA-AES256-GCM-SHA384. Ang unang token ay ang key-exchange family: ephemeral elliptic-curve Diffie-Hellman. Ang pangalawa ay ang authentication family: RSA. Ang natitira ay naglalarawan ng record protection at ng hash na ginagamit sa handshake.

Gumagamit ang ECDHE-ECDSA suite ng parehong key-exchange family na may ibang paraan ng authentication, kaya nangangailangan ito ng elliptic-curve certificate. Gumagamit ang DHE-RSA suite ng finite-field ephemeral Diffie-Hellman na may RSA authentication, at talagang nangangailangan iyon ng DH parameters.

Basahin ang pangalan ng suite mula kaliwa pakanan at italaga ang bawat bahagi sa trabaho nito. Kapag nahiwalay na ang mga token, nagbabago ang tanong mula sa «tumutugma ba ang certificate ko sa dh none» patungo sa «pinapayagan ba ng server ko ang suite na ang key exchange ay hindi nangangailangan ng DH file».

Ano ang aktwal na hindi pinagana ng dh none

Sinasabi ng dh none sa server na huwag mag-load ng finite-field DH parameter file. Hindi nito hindi pinapagana ang authentication, certificate validation, o ang TLS mismo. Hinihiling nito na ang napagkasunduang key exchange ay hindi mangailangan ng mga parameter na iyon, na sa praktika ay nangangahulugang ECDHE suite o TLS 1.3 handshake.

Mula sa pangangailangang iyon nagmumula ang pagkasira. Kung ang TLS cipher policy ng server ay limitado sa DHE suites, o ang client ay nag-aalok lamang ng mga iyon, ang pagtanggal ng parameter file ay walang natitirang magagamit na paraan ng key exchange at nabibigo ang handshake. Karaniwang lumilitaw ang error sa handshake ng control channel, bago ang anumang user authentication. Basahin ang cipher list bago sisihin ang nawawalang file.

Sa panig ng elliptic curve, ang curve ay pinipili ng TLS configuration ng server, at ang OpenVPN ay nag-aalok ng opsyon upang piliin ito sa mga lumang branch. Hinahawakan ng TLS 1.3 ang group negotiation sa loob ng protocol at hindi tumitingin sa DH file.

dh none ay hindi pagbaba ng seguridad sa sarili nito. Ang lakas ng exchange ay nakasalalay sa curve at suite na aktwal na napagkasunduan, kaya ang susunod na hakbang ay tingnan kung ano ang pinili ng mga peer, hindi ang nawawalang file.

Kumpirmahin ang negotiation bago mag-edit

Itaas ang verbosity ng server at client at basahin ang control-channel line na ini-print ng OpenVPN pagkatapos ng koneksyon. Pinangalanan nito ang TLS version at ang napagkasunduang cipher, at iniuulat ang key type ng certificate ng peer. Ang nag-iisang linyang iyon ang sumasagot sa tanong na hinuhulaan lamang ng configuration file.

Kung nagpapakita ito ng TLS 1.2 na may ECDHE-RSA suite at RSA certificate, ang kombinasyon ay eksaktong inaasahan ng dh none, at walang dapat ayusin. Kung nagpapakita ito ng DHE suite o pagkabigo ng handshake na walang common cipher, ang pag-aayos ay nasa cipher policy o kakayahan ng client, hindi sa certificate.

Subukan ang pinakalumang client na balak mong suportahan, dahil ang kasalukuyang client ay maaaring makipag-negotiate ng TLS 1.3 habang ang mas luma ay limitado sa TLS 1.2 suites. Kung walang overlap ang pinakalumang client, palawakin ang pinapayagang suites o i-upgrade ang endpoint na iyon.

Huwag patayin ang certificate verification upang malampasan ang pagkabigo ng handshake. Sinasabi ng pagkabigo na hindi nagkasundo ang mga peer sa key exchange, at ang pagpatay sa check ay nag-aalis ng garantiya ng pagkakakilanlan nang hindi nilulutas ang kasunduan.

Checklist: RSA ba ang certificate, pinapayagan ba ang ECDHE suite, ipinapakita ba ng log ang suite na iyon, at nakikipag-negotiate rin ba ang pinakalumang suportadong client? Kung oo ang lahat ng apat, ginagawa ng dh none ang trabaho nito.