Pagsubaybay sa mga control packet ng OpenVPN: tls-auth bago ang TLS

Ang pagpalya ng tls-auth ay karaniwang iniuulat bilang problema sa handshake, at hindi kailanman naging ganoon. Sinusuri ang HMAC sa control packet bago mangyari ang anumang pagpoproseso ng TLS, kaya ang hindi tugmang key o direksyon ay gumagawa ng pagpalya na mukhang problema sa sertipiko at napagpapasyahan dalawang layer nang mas maaga. Kung ituturing ang envelope bilang sariling bagay, maikli ang diagnosis: basahin ang mga field, tiyakin na maagang nangyayari ang pagsusuri, pagkatapos ay ihambing ang tatlong bagay na dapat pagkasunduan ng dalawang dulo.

Basahin ang envelope ayon sa pagkakasunod-sunod ng pagbuo nito

Ang control packet ay may session identifier, ang opsyonal na tls-auth HMAC, impormasyon ng pag-uulit at pagtanggap, at maaasahang message identifier, at pagkatapos ay ang payload ng uri ng mensahe. Kapag ang mensahe ay handshake message, ang payload ay TLS ciphertext. Iyon ang buong ugnayan: ang TLS material ay naglalakbay sa loob ng mensaheng pinoprotektahan na ng envelope. Tingnan ang sanggunian ng network protocol ng OpenVPN na naglilista ng mga field ng control channel sa ganoong pagkakasunod-sunod.

Ang layer ng pagiging maaasahan ay madaling mapagkamalang criptograpiya. Ang mga pagtanggap, muling pagpapadala at message identifier ay umiiral upang ang mga control message ay dumating nang isang beses at ayon sa pagkakasunod-sunod sa hindi maaasahang transportasyon. Hindi ang mga ito ay authentication, at ang tamang message identifier ay walang pinapatunayan tungkol sa kung sino ang nagpadala ng packet.

Panatilihing konseptwal ang pagpapangkat na ito. Hindi ito diagram ng pagkakasunod-sunod ng byte at hindi sapat upang kalkulahin ang tag, dahil ang mga field na pumapasok sa HMAC ay nakadepende sa implementasyon, bersyon at mode.

Ipakita na maagang nangyayari ang pagsusuri bago ang handshake

Ang tumatanggap na may hawak ng shared key ay maaaring i-verify ang HMAC at agad na itapon ang pekeng packet, nang hindi naglalaan ng handshake state o gumagawa ng public-key work. Sinasaklaw din ng proteksyon ang mga unang handshake packet, at iyon ang dahilan kung bakit lumilitaw ang maling key bilang bigong koneksyon at hindi bilang huling error sa authentication.

Taasan ang verbosity ng daemon at panoorin ang control channel sa halip na ang tun device:

openvpn --config /etc/openvpn/server.conf --verb 6

Ang hinahanap mo ay ang pagpalya ng HMAC verification ng control channel na iniuulat sa antas ng packet, bago ang anumang TLS alert. Ang TLS alert sa log ay nangangahulugang tinanggap ang envelope at lumipat papasok ang pagpalya, na ibang imbestigasyon na may ibang lunas.

Ang paghawak ng direksyon ay narito rin. Kapag ginamit ang static key file sa tls-auth, ang dalawang dulo ay kumukuha ng magkasalungat na direksyon ng key, at ginagamit ng protocol ang paghahating iyon upang ang nahuling packet ay hindi maipabalik sa nagpadala nito. Ang pagbaliktad ng direksyon ay nagpapanatili ng parehong key at pumapalya pa rin ang bawat packet. Palitan ang isang dulo sa isang pagkakataon, pagkatapos ay i-restart ang dalawang daemon upang magkargang magkasama ang pares.

Itugma ang key, direksyon at digest sa dalawang dulo

Tatlong halaga ang dapat magtugma at isa lamang sa kanila ang file. Ang nilalaman ng static key ay dapat magkapareho sa dalawang dulo, ang direksyon ay dapat magkasalungat, at ang digest na ginamit para sa HMAC ay dapat magtugma. Suriin ang configuration bago hawakan ang key material, dahil ang isang baliktad na direksyon ay nagpapaliwanag ng mas maraming pagpalya kaysa sa sirang file:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Bumuo ng shared secret gamit ang tool at hindi ang editor, at panatilihing mahigpit ang mga pahintulot:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Tinatanggap ng lumang release ang bahagyang ibang pagkakasunod-sunod ng opsyon para sa pagbuo ng key, at ang mga profile na isinulat para sa mga release na iyon ay umiikot pa rin. Ang nabuong file ay parehong uri ng bagay sa dalawang kaso, kaya ang pagsusuri ay kung pareho ang byte sa dalawang dulo, hindi kung aling baybay ang gumawa nito.

Huwag ipagkamali ang tls-auth sa tls-crypt. Pareho nilang pinoprotektahan ang control channel, ngunit ini-encrypt din ito ng tls-crypt at itinatago ang handshake mula sa mga nagmamasid, at pinapalitan ang paghahati ng direksyon ng sarili nitong paghawak ng key. Ang profile na gumagamit ng isa ay hindi gagana sa kapares na naka-configure para sa isa pa, at walang pag-tune ng digest ang nagsasara ng puwang na iyon.

Kopyahin muli ang tag mula sa tunay na format lamang

Ang byte-exact na paggawa muli ay hiwalay na gawain sa pagpapatakbo ng VPN, at gumagana lamang ito sa tunay na input: ang implementasyon at bersyon na bumuo ng packet, ang napiling digest, ang direksyon, at ang aktwal na byte kabilang ang session identifier at acknowledgement array. Ang tekstwal na presentasyon ng listahan ng field ay hindi ang mga byte na iyon.

Ang haba ng tag ay nagmumula sa digest, kaya ang palagay na fixed length ay nabasag sa sandaling may magbago nito. I-hash ang packet tulad ng ginagawa ng implementasyon, hindi tulad ng presentasyon ng talahanayan sa blog post, at ihambing sa capture na kinuha mula sa parehong kapares sa halip na sa inaasahang hinango mo sa kamay.

Ilayo ang pagsasanay na iyon sa mga production profile. Wala sa paggawa muli ng tag ang nagsasabi sa iyo kung dapat i-enable ng deployment ang proteksyon.

Ibalik ang hindi pagkakatugma nang hindi inaalis ang proteksyon

Ang nakakaakit na pagsubok ay burahin ang tls-auth, tingnan na nagtagumpay ang koneksyon at tapusin na mali ang key. Ang sagot na iyon ay kumukuha ng proteksyon sa iyo at walang itinuturo tungkol sa alin sa tatlong halaga ang hindi tugma. Sa halip, kunin ang aprubadong tugmang configuration mula sa panig ng server at ihambing doon.

Ihanda ang pagbabago upang maibalik ito. Itago ang nakaraang configuration at key file ng server, ilapat ang itinamang pares, i-verify na natatapos ng client ang handshake, at pagkatapos lamang alisin ang backup. Kung pumapalya ang mga client pagkatapos ng pagbabago, ibalik ang mga nakaraang file sa halip na mag-imbento ng ikatlong variant sa panahon ng outage. Ang pagbalik ay dapat isang utos na alam mo na bago ka magsimula.

Sa wakas, tandaan ang ibig sabihin ng pumasa na pagsusuri. Pinatutunayan nito na hawak ng kapares ang shared key, hindi na awtorisado ang sertipiko o account nito, at wala itong sinasabi tungkol sa napagkasunduang cipher ng data channel. Ang awtorisasyon at proteksyon ng data ay itinatag mamaya, kaya ang malinis na pagsusuri ng envelope ay panimulang punto at hindi hatol.