OpenVPN tls-ciphersuites kumpara sa tls-version-min: ano ang ipinapatupad ng bawat isa

Tatlong magkakaibang katotohanan ang pinagsasama-sama sa isang linya sa karamihan ng usapan sa OpenVPN TLS: kung ano ang kayang gawin ng build ng kliyente mo, kung ano ang pinapayagan ng profile, at kung ano talaga ang napagkasunduan ng session. Ang maikling listahan ng TLS 1.3 suite ay kalahati lang ang sinasagot sa gitnang tanong, at wala itong sinasabi tungkol sa ilalim na hangganan ng bersyon ng protocol. Sundan ang mga pagsusuri sa ibaba nang sunod-sunod at huminto sa unang hindi tumatayo, dahil ipinapalagay ng bawat susunod na pagsusuri na ang mga nauna ay naayos na.

Suriin ang build bago magbasa ng anumang listahan

Hindi maaaring magdagdag ang direktiba ng configuration ng suporta sa protocol sa isang binary na wala nito. Magsimula sa banner ng bersyon, na nagpapangalan sa naka-compile na crypto library:

openvpn --version

Ang 2.6 build na naka-link sa OpenSSL ay tumatanggap ng parehong tls-cipher at tls-ciphersuites. Ang build na may mbed TLS ay walang anumang pagpili ng TLS 1.3 suite, at minamarkahan ng manual 2.6 ang tls-ciphersuites bilang opsyon ng OpenSSL. Kung muling itatayo ang server gamit ang ibang backend, maaaring baguhin ng parehong profile ang pag-uugali nito nang walang kahit isang linya ng configuration na mababago.

Habang narito ka, patakbuhin ang openvpn --show-tls at itabi ang output. Iyon ang imbentaryo na ihahambing mo mamaya, at mura itong kunin bago magsimulang mag-edit ng profile ang sinuman.

Isulat ang banner at listahan sa ticket ng pagbabago, hindi sa chat window. Kapag dalawang tao ang nagtatalo kung makakapag-alok ba ng suite ang isang kliyente sa loob ng anim na linggo, ang nakuhang output ang magpapasya nito sa isang linya.

Panatilihing hiwalay ang mga hangganan ng bersyon sa mga listahan ng cipher

Sa manual 2.6 tatlong kontrol ang mga ito, hindi isa:

• Itinatakda ng tls-cipher ang patakaran ng cipher para sa TLS 1.2 at mas lumang bersyon, at ipinapasa sa listahan ng cipher ng OpenSSL;
• Pinipili ng tls-ciphersuites ang mga TLS 1.3 suite;
• Nililimitahan ng tls-version-min at tls-version-max ang mga bersyon ng protocol na maaaring gamitin ng koneksyon.

Kaya ang maingat na ginupit na listahan ng TLS 1.3 suite ay walang pinapatunayan tungkol sa isang lumang bersyon na pinapayagan pa rin. Kung ang pangangailangan ay «TLS 1.3 lamang», ang ilalim na hangganan ng bersyon ang nagdadala nito, at ang listahan ng suite ay nagpapaliit lamang ng mga pagpipilian sa loob ng hangganang iyon:

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

Dalawang gawain ang ginagawa ng pares na iyon. Ang pagbura ng isa sa mga linya ay nag-iiwan sa isa na nagpapatupad ng mas mababa kaysa sa iniisip mo, at iyon mismo ang kabiguan na dahilan kung bakit may ganitong buong pagsusuri.

Ang data channel ang ikaapat na kontrol. Nakikipag-usap ang data-ciphers sa simetriko na cipher sa loob ng tunnel, at walang sinasabi ang resulta nito tungkol sa bersyon ng TLS ng control channel. Ang makita ang AES-256-GCM sa buod ng session ay hindi ebidensya tungkol sa TLS 1.3 sa alinmang direksyon.

Basahin ang show-tls bilang lokal na imbentaryo

--show-tls ay naglilista ng mga suite na sinusuportahan ng crypto library na naka-link sa binary na ito, sa pagkakasunod-sunod ng preference. Hindi ito ulat mula sa gateway. Sinasabi ng manual nang malinaw na ang listahan ay galing sa lokal na library, na nangangahulugang ang laptop na may OpenSSL 3.x at ang router na may mas lumang build ay magpi-print ng magkaibang listahan habang kausap ang parehong server.

Ipagpalagay na sinusuportahan ng kliyente ang mga suite A, B at C at pumipili ang isang session ng B. Hindi nito itinatatag kung pinapayagan ng server ang A o C, o kung ang B ang tanging pinapayagang pagpipilian nito. Panatilihing hiwalay ang tatlong linya, at karamihan sa nakakalitong usapin sa TLS ay kusang malulutas.

Sulit pa ring itabi ang imbentaryo. Kapag nabigo ang isang session, ang paghahambing ng listahan ng library sa listahan ng profile ay nagsasabi kung may pagkakataon ang kliyente na i-alok ang gusto ng server. Ipinapakita rin nito kung tahimik na tinanggal ng pagbabago sa backend ang TLS_CHACHA20_POLY1305_SHA256 mula sa pool na umaasa ang mas lumang kliyente — ang uri ng regression na lumilitaw bilang kakaunting user na hindi makakonekta habang walang napapansin ang iba.

Tanungin ang gateway ng isang bagay na kayang sagutin

Kung ikaw ang namamahala ng serbisyo, siyasatin ang epektibong configuration ng tumatakbong instance sa halip na file sa disk. Maaaring na-start ang OpenVPN sa ibang --config path, maaaring kumukuha ng mga include, at maaaring hindi pa na-restart mula nang i-edit. Ang patakaran ng tumatakbong daemon ang nakakaharap ng mga kliyente.

Kung hindi ikaw ang namamahala nito, humingi sa operator ng sinusuportahang pangangailangan ng kliyente o limitadong acceptance test. Ang tinanggihang pagtatangka ay hindi awtomatikong tinanggihang suite: ang ilalim na hangganan ng bersyon, mga pagsusuri sa pagkakakilanlan ng sertipiko tulad ng remote-cert-tls, o hindi pagtutugma ng tls-auth at tls-crypt ay maaaring tapusin ang palitan bago pa maging mahalaga ang pagpili ng suite. Basahin ang error ng server bago baguhin ang listahan ng kliyente, dahil ang «handshake failed» ay sumasaklaw sa apat na magkaibang dahilan at isa lamang sa mga ito ang hindi pagtutugma ng cipher.

Hindi rin nagre-reproduce ng tanong ang pagtutok ng openssl s_client sa VPN port. Tumatakbo ang control channel sa loob ng sariling framing ng OpenVPN, kaya ang raw TLS probe ay sumusubok ng ibang protocol sa port na may inaasahang iba. Anumang konklusyon mula rito ay tungkol sa probe, hindi sa tunnel.

Itala ang dalawang resulta at panatilihing hiwalay

Ang bagong pinahintulutang session ay gumagawa ng linya ng control channel na nagpapangalan sa bersyon ng protocol at napiling cipher, at hiwalay na linya ng data channel na nagpapangalan sa cipher ng tunnel. Kunin ang dalawa kasama ang bersyon ng kliyente at pangalan ng profile, at itala kung aling instance ng server ang sumagot:

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

Pagkatapos ay basahin ang dalawang linya mula sa file na iyon, hindi mula sa memorya. Ang pares ang ebidensya; ang pangalan ng suite lamang ay preference, at ang hangganan ng bersyon ay hiwalay na pahayag tungkol sa tinatanggihan ng server.

Gawin ang mga pagsusuri sa ganitong pagkakasunod-sunod. Kumpirmahin ang build at backend gamit ang --version. Kunin ang --show-tls bago baguhin ang anuman. Sabihin ang kinakailangang ilalim na hangganan ng bersyon nang hiwalay sa listahan ng suite. Kumpirmahin ang epektibong patakaran ng tumatakbong instance sa may-ari nito. Obserbahan ang isang pinahintulutang session at, kung pinapayagan ng plano, isang tinanggihang pagtatangka na may lumang bersyon. Itala ang mga resulta ng control channel at data channel bilang hiwalay na natuklasan.

Kung hindi matugunan ng kinakailangang kliyente ang bagong minimum, gawin ang desisyong iyon sa migration o exception nang tahasan sa halip na tahimik na babaan ang isang walang kaugnayang tuntunin sa pagtanggap upang magmukhang tapos ang rollout.