OpenVPN: EC at ED — bakit hindi hagdan ng lakas ang mga pangalang ito

Ilagay ang ec, ed, ecdh, ecdsa, auth at isang listahan ng TLS cipher nang magkatabi sa isang profile, at ang file ay magsisimulang magmukhang isang manibela ng lakas na may anim na posisyon. Hindi ito ganoon. Bawat pangalan ay sumasagot sa ibang tanong, at ang dalawang profile na naiiba lamang sa isa sa mga ito ay hindi laging mas malakas o mas mahina kaysa sa isa. Ang pagsasaayos ng mga pangalan ayon sa gawaing ginagawa nila ay tumatagal ng mga limang minuto at pumipigil sa karamihan ng masasamang pagbabago na ginagawa ng mga tao sa isang gumaganang configuration.

Ang pagsasaayos sa ibaba ay nagsisimula sa kalituhan mismo, pagkatapos ay lumalawak patungo sa mga bahagi ng profile na talagang nagpapasya kung ano ang nagpoprotekta sa iyong trapiko. Bawat seksyon ay humahawak ng isang maling pagbasa at ipinapakita kung ano talaga ang nakakabit sa pangalan.

Dalawang titik, dalawang magkaibang tanong

Ang pares na pinakamaraming pinagtatalunan ay EC at ED, at ang pagtatalo ay karaniwang ipinapalagay na magkaribal silang sagot sa isang tanong. Hindi man lang sila nasa iisang aksis. Inilalarawan ng EC ang isang pamilya ng matematika: elliptic-curve cryptography, kung saan ang seguridad ay nagmumula sa hirap ng discrete logarithm sa isang curve sa halip na sa isang malaking finite field.

Inilalarawan ng ED ang isang hugis ng curve sa loob ng pamilyang iyon. Ang twisted Edwards curves ay isang representasyon na pinili para sa bilis at para sa paglaban sa ilang pagkakamali sa implementasyon, at Ed25519 ang pangalang karaniwang tinutukoy ng mga tao. Ang curve ay hindi kalaban ng elliptic-curve cryptography; isa itong paraan ng pagsulat ng isang elliptic curve. Ang pagbasa sa ED bilang “ang mas bago at mas malakas na EC” ay ang unang maling liko, at ang lahat ng sumusunod ay kadalasang mali sa parehong direksyon.

Magkaibang gawain ang pagpirma at pagpapalitan

Kapag naayos na ang tanong ng pamilya, ang natitirang mga pangalan ay nahahati sa dalawang hanay na hindi kailanman nagpapalitan. Ang isang hanay ay pumipirma, ang isa ay sumasang-ayon sa isang pinagsasaluhang sikreto.

Parehong pumipirma ang EdDSA at ECDSA, ngunit magkaibang scheme sila na may magkaibang format ng key, kaya ang certificate na inilabas para sa isa ay hindi magagamit bilang ang isa pa. Ang EdDSA ay tinukoy para sa maliit na hanay ng mga curve; hindi kabilang doon ang P-256, kaya ang P-256 certificate ay nagbe-verify sa ECDSA at hindi kailanman sa Ed25519.

Walang katumbas na tinatawag na EdDH ang hanay ng palitan. Ang ephemeral na kasunduan sa isang Curve25519 key ay X25519, at ito ay ECDH na may partikular na curve, eksaktong tulad ng sa P-256. Ang Ed25519 ay mahigpit na nangangahulugang ang signature scheme, kahit na ang pangalan ay maluwag na ginagamit para sa palitan dahil magkamag-anak ang dalawang curve: ang Edwards form na ginagamit sa pagpirma at ang Montgomery form na ginagamit para sa X25519 ay naglalarawan ng parehong underlying group.

Bakit walang dh file ang isang EC profile

Ang isang dh file ay naglalaman ng mga paunang ginawang parameter para sa finite-field Diffie-Hellman, at umiiral ang mga parameter na iyon dahil ang isang malaking prime at isang generator ay kailangang magmula sa isang lugar. Hindi kailangan ng mga ito ang isang elliptic-curve exchange: ang pinangalanang curve ang siyang parameter set, at alam na ito ng dalawang panig. Iyon ang buong dahilan kung bakit maaaring laktawan ng isang EC profile ang directive.

Dalawang sitwasyon ang gumagawa pa rin ng dh line sa isang profile na kung hindi ay mukhang moderno. Ang una ay isang pangalawang listener o isang mas lumang peer na tunay na nakikipagnegosyo sa finite-field groups. Ang pangalawa ay natirang teksto na kinopya mula sa isang template ng panahon ng RSA at hindi kailanman inalis. Ang isang profile na nagpangalan ng curve para sa palitan at naglo-load pa rin ng 2048-bit dh file ay hindi nagiging mas secure dahil ginawa ito; may dala lamang itong hindi ginagamit na artifact.

Inalis ng TLS 1.3 ang key exchange sa pangalan

Ihambing ang TLS_AES_256_GCM_SHA384 sa TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 at ang mas maikling pangalan ay mukhang isang downgrade. Ito ay isang pagpapalit ng pangalan, at ang dahilan ay istruktural: inalis ng TLS 1.3 ang static RSA at finite-field Diffie-Hellman key exchange, kaya ang isang ephemeral elliptic-curve exchange ang natitirang tanging opsyon na hindi PSK. Ang pangalanan ito sa bawat suite ay mag-uulit ng parehong katotohanan ng isang dosenang beses.

Nawala ang uri ng certificate sa pangalan dahil sa kaugnay na dahilan. Sa 1.3, ang certificate ay nagpapatotoo sa handshake signature, hindi sa key agreement, kaya hindi na ito pumipili ng suite. Iyon din ang dahilan kung bakit may hiwalay na cipher list para sa 1.3 sa configuration: ang mga suite ay pinangalanang muli at inayos muli, hindi pinahina.

Isang kahihinatnan ang dapat sabihin nang tuwiran. Ang ECDHE ay isang key-exchange algorithm at hindi kailanman isang cipher. Ang isang suite na inilarawan bilang “elliptic” ay may sinasabi tungkol sa kung paano nakarating ang dalawang peer sa isang shared key, at walang sinasabi tungkol sa kung ano ang mag-e-encrypt sa payload pagkatapos.

auth ang nagpapatotoo sa mga packet, hindi sa payload

Pinipili ng auth directive ang HMAC digest na nagpapatotoo sa mga packet, at ang makasaysayang default nito ay SHA1. Sa isang non-AEAD data cipher, kinukwenta ng OpenVPN ang digest sa ibabaw ng ciphertext at idinadagdag ito, isang encrypt-then-MAC na kaayusan na siyang gumagawa sa padding manipulation na hindi praktikal.

Ang alamat dito ay ang pagtataas ng auth sa SHA512 ay nagpapatibay sa tunnel. Hindi nito itinataas ang lakas ng encryption, at kung ang napagkasunduang data cipher ay isang AEAD mode tulad ng AES-256-GCM, ang digest ay hindi inilalapat sa mga data packet. Ang GCM tag ay nagpapatotoo na sa mga ito, at ang auth value ay inilalaan para sa control-channel HMAC at para sa anumang non-AEAD cipher na ginagamit pa.

Kaya mahalaga ang directive, ngunit mahalaga ito sa mas makitid na lugar kaysa sa ipinahihiwatig ng posisyon nito sa file. Ang pagsuri kung aling cipher ang tunay na napagkasunduan ay nagsasabi sa iyo kung ito ay nalalapat man.

Basahin ang profile ayon sa hanay, hindi sa ranggo

Tatlong tanong ang malinaw na naghihiwalay sa mga layer, at bawat isa ay sinasagot ng ibang bahagi ng napagkasunduang session. Aling cipher ang nagpoprotekta sa payload? Aling tag o digest ang tumitiyak para sa bawat packet, at kailangan pa ba ito ng cipher na ginagamit? Kaninong certificate ang nagsara ng handshake, at ang control channel ba ay dagdag na binabantayan ng tls-auth o tls-crypt?

Walang anuman sa EC o ED na label ang nagtatakda sa alinman sa tatlong iyon, at ang pangalan ng suite lamang ay wala ring natatakdaan. Ang napagkasunduang resulta ang tanging ebidensya, kaya basahin iyon sa halip na hulaan ang lakas mula sa bokabularyo:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Ang unang command ay nagsasabi sa iyo kung aling signature scheme ang tunay na ginagamit ng iyong certificate, at iyon ang tanging maaasahang paraan upang malaman kung ECDSA o Ed25519 ang pinapatakbo mo. Ang pangalawa ay nagpapakita ng control-channel line na itinala ng client para sa session, kasama ang TLS version at ang suite na napili nito. Kung ang isang pagbabago sa profile ay hindi makatwiran ng isa sa dalawang output na iyon, malamang na pagbabago ito sa pangalan at hindi sa isang katangian.