Handshake ng VPN na nabigo—talaga bang downgrade attack ito?

Ang handshake na nagtatapos sa error ay parang pag-atake hanggang tingnan mo ang mensahe, at kadalasan ay aritmetika ito: walang ibinahaging proposal, isang sertipikong nag-expire, o isang packet na hindi kailanman dumating. Ang downgrade attack ay isang tiyak na bagay: isang kalaban na itinutulak ang dalawang dulo patungo sa mas mahinang pag-uugali kaysa sa pipiliin nila, at nag-iiwan ito ng ibang ebidensya. Ang ituring ang bawat kabiguan bilang masamang hangarin ay nagpapadala sa iyo na maghanap ng biktimang maaaring wala naman, habang ang ituring ang tunay na downgrade bilang bug sa configuration ay iniiwan ang mas mahinang resulta sa puwesto. Magkaiba ang gastos ng dalawang pagkakamali, at isa lang ang murang ayusin.

Ano ang talagang binabago ng downgrade attack

Ang layunin ay hindi basagin ang cipher at hindi hulaan ang susi. Ito ay impluwensyahan ang negosasyon upang ang dalawang panig ay huminto sa mas lumang bersyon o mas mahinang algorithm na kayang hawakan ng attacker, o gawing maniwala ang isang panig na ang isa ay sumusuporta lamang doon.

Ang nababago ay ang kasunduan, hindi ang authentication. Kung mababago ng attacker ang alok nang hindi natukoy, maaari pa ring tapusin ng mga peer ang handshake at maaari pa ring mag-authenticate sa isa't isa, ngunit gamit ang mga parameter na mas gusto ng attacker. Kaya ang kawili-wiling tanong ay kung ang negosasyon mismo ay sakop ng proteksyon sa integridad.

Bakit ang negosasyon mismo ay dapat ma-authenticate

Ginagawang tahasan ng TLS 1.3 ang proteksyong iyon. Ang client na nag-alok ng mas bagong bersyon ay maaaring matukoy ang server na tahimik na umurong, dahil ang random na halaga ng server ay may takdang pattern kapag nakikipagnegosasyon sa 1.2 o mas mababa, at kailangang ihinto ito ng client kapag nakita. Ang buong transcript ay sakop din ng mga huling mensahe, kaya ang pagbabago kahit saan sa negosasyon ay nabibigo mamaya sa halip na tahimik na makalusot.

Ang mga lumang bersyon ng protocol ay may mahihinang kuwento, at iyon ang eksaktong dahilan kung bakit mahalaga ang mga patakaran sa fallback. Ang endpoint na TLS 1.0 sa parehong configuration ay hindi downgrade attack; ito ay pinapayagang resulta na pinili mong payagan. Ang pagkakaiba ay kung ang mas mahinang resulta ay nagmula sa protektadong desisyon o sa hindi protektadong landas na maaaring impluwensyahan ng isang tagapamagitan. Kapag ganoon ang pagkakasabi, karamihan ng insidente ay nagiging tanong sa configuration.

Iba ang pag-uugali ng IKEv2 ngunit nakasandal sa parehong ideya. Ang proposal ay dinadala sa palitan na mamaya ay nag-authenticate sa dalawang panig, kaya ang middlebox na nagsusulat muli ng mga algorithm ay sumisira sa authentication sa halip na gabayan ito. Pinoprotektahan ng control channel ng OpenVPN ang negosasyon nito gamit ang TLS at pagkatapos ay ginagamit ang channel na iyon upang magkasundo sa mga cipher ng data channel, kaya ang linya ng log ng control channel ang kawili-wili.

Ang naka-configure na compatibility ay hindi pag-atake

Maaaring sadyang payagan ng administrator ang mas lumang pagpipilian upang suportahan ang isang dokumentadong client, at ang desisyong iyon ay nakikita sa configuration. Hindi kayang likhain ng attacker ang configuration na iyon; maaari lang nitong samantalahin ang landas na nagpapahintulot na impluwensyahan ang alok.

Ang mapanganib na pag-aayos ay ang nag-aalis ng ebidensya ng pagkakaiba. Ang pagpapagana ng bawat legacy option, pag-off ng verification ng sertipiko o pagtanggap ng anumang cipher upang mawala ang error ay nagpapalawak sa tatanggapin ng endpoint, at nag-aalis ng mga pagsusuring mag-uulat ng mas mahinang resulta.

Kung kailangang panatilihin ang isang lumang opsyon, pangalanan ang dahilan at ang client sa komento ng configuration, pagkatapos ay limitahan ang opsyon sa profile na nangangailangan nito. Ang compatibility exception na limitado sa isang listener ay maaaring i-audit; ang inilapat sa buong mundo ay mas mahinang default lamang na walang naaalalang pumili.

Basahin ang kabiguan bago pangalanan ang dahilan

Itago ang eksaktong error string, ang mga bersyon ng client at server at ang oras bago ang anumang pagbabago. Pagkatapos ay uriin: hindi ba nagkasundo ang mga panig sa proposal, nabigo ang landas ng packet, o tinanggihan ng isang panig ang parameter na minsang tinatanggap?

Ang hindi pagtutugma ng proposal ay karaniwang pinangalanan ang mga salarin na bersyon o algorithm at nabibigo sa parehong punto bawat oras. Ang problema sa routing o MTU ay humihinto o nag-time out, at madalas magbago ayon sa network. Ang nag-expire na sertipiko ay nagdudulot ng error sa verification, hindi sa negosasyon.

Wala sa mga ito ang ebidensya ng attacker. Ang mag-attribute ng masamang dahilan sa unang kabiguan ay ang pagkakamali, dahil itinatago nito ang deterministikong bug na mabibigo muli bukas.

Kumpirmahin kung ano talaga ang napili

Pagkatapos ng anumang pagwawasto, basahin ang na-negosyong resulta sa halip na maniwala na umangat ang koneksyon. Ang koneksyong nagtagumpay dahil inalis ang verification ay ang resultang sinusubukan mong iwasan. Ipinapakita ng dalawang command sa ibaba ang napiling bersyon at cipher para sa endpoint na may TLS sa harap, at ang linya ng control channel mula sa log ng server na OpenVPN.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Ihambing ang resulta sa configuration na nilayon mo, hindi sa kung ano ang kumokonekta ngayon. Kung ang napiling bersyon ay mas luma kaysa sa pinapayagang minimum, ang profile o ang fallback list ang lugar na dapat tingnan, at ang sagot ay ayusin ang listahang iyon, hindi magdeklara ng pag-atake at itayong muli ang lahat sa paligid nito.