Noong nakaraan, ang mga sertipiko ay madalas na nag-expire dahil kailangan itong i-renew nang manu-mano. Nakalimutan lang gawin ng mga tao. Sa pagdating ng Let's Encrypt at ang automatic update procedure, mukhang dapat malutas ang problema. Ngunit kamakailan lamang
Kung sakaling napalampas mo ang kuwento, noong hatinggabi noong Mayo 4, 2019, halos lahat ng mga extension ng Firefox ay biglang tumigil sa paggana.
Tulad ng nangyari, ang napakalaking kabiguan ay naganap dahil sa katotohanan na ang Mozilla
Mabilis na inilabas ng Mozilla ang Firefox 66.0.4 patch, na nilulutas ang problema sa isang di-wastong sertipiko, at ang lahat ng mga extension ay bumalik sa normal. Inirerekomenda ng mga developer na i-install ito at
Gayunpaman, muling ipinapakita ng kuwentong ito na ang pag-expire ng sertipiko ay nananatiling isang mahalagang isyu ngayon.
Kaugnay nito, kagiliw-giliw na tingnan ang isang medyo orihinal na paraan kung paano hinarap ng mga developer ng protocol ang gawaing ito
DNSCrypt
Ang DNSCrypt ay isang DNS traffic encryption protocol. Pinoprotektahan nito ang mga komunikasyon sa DNS mula sa mga interception at MiTM, at pinapayagan ka ring i-bypass ang pagharang sa antas ng query ng DNS.
Binabalot ng protocol ang trapiko ng DNS sa pagitan ng kliyente at server sa isang cryptographic na konstruksyon, na tumatakbo sa mga protocol ng transportasyon ng UDP at TCP. Para magamit ito, dapat suportahan ng client at DNS resolver ang DNSCrypt. Halimbawa, mula noong Marso 2016, pinagana ito sa mga DNS server nito at sa browser ng Yandex. Ang ilang iba pang mga provider ay nag-anunsyo din ng suporta, kabilang ang Google at Cloudflare. Sa kasamaang palad, hindi marami sa kanila (152 pampublikong DNS server ang nakalista sa opisyal na website). Ngunit ang programa
Paano gumagana ang DNSCrypt? Sa madaling salita, kinukuha ng kliyente ang pampublikong key ng napiling provider at ginagamit ito upang i-verify ang mga certificate nito. Ang mga panandaliang pampublikong key para sa session at ang cipher suite identifier ay naroon na. Hinihikayat ang mga kliyente na bumuo ng bagong susi para sa bawat kahilingan, at hinihikayat ang mga server na baguhin ang mga susi tuwing 24 na oras. Kapag nagpapalitan ng mga susi, ginagamit ang X25519 algorithm, para sa pag-sign - EdDSA, para sa block encryption - XSalsa20-Poly1305 o XChaCha20-Poly1305.
Isa sa mga developer ng protocol na si Frank Denis
Una, ito ay lubhang kapaki-pakinabang para sa seguridad: kung ang server ay nakompromiso o ang susi ay na-leak, kung gayon ang trapiko kahapon ay hindi ma-decrypt. Ang susi ay nagbago na. Ito ay malamang na magdulot ng problema para sa pagpapatupad ng Yarovaya Law, na pumipilit sa mga provider na iimbak ang lahat ng trapiko, kabilang ang naka-encrypt na trapiko. Ang implikasyon ay maaari itong i-decrypt sa ibang pagkakataon kung kinakailangan sa pamamagitan ng paghiling ng susi mula sa site. Ngunit sa kasong ito, hindi ito maibibigay ng site, dahil gumagamit ito ng mga panandaliang key, tinatanggal ang mga luma.
Ngunit ang pinakamahalaga, isinulat ni Denis, pinipilit ng mga short-term key ang mga server na mag-set up ng automation mula sa unang araw. Kung ang server ay kumokonekta sa network at ang mga key change script ay hindi na-configure o hindi gumagana, ito ay agad na matutukoy.
Kapag binago ng automation ang mga susi kada ilang taon, hindi ito maaasahan, at maaaring makalimutan ng mga tao ang tungkol sa pag-expire ng certificate. Kung babaguhin mo ang mga susi araw-araw, agad itong matutukoy.
Kasabay nito, kung ang automation ay naka-configure nang normal, hindi mahalaga kung gaano kadalas binago ang mga susi: bawat taon, bawat quarter o tatlong beses sa isang araw. Kung gumagana ang lahat ng higit sa 24 na oras, gagana ito magpakailanman, isinulat ni Frank Denis. Ayon sa kanya, ang rekomendasyon ng pang-araw-araw na pag-ikot ng susi sa pangalawang bersyon ng protocol, kasama ang isang handa na imahe ng Docker na nagpapatupad nito, ay epektibong nabawasan ang bilang ng mga server na may mga nag-expire na sertipiko, habang sabay-sabay na pagpapabuti ng seguridad.
Gayunpaman, nagpasya pa rin ang ilang provider, para sa ilang teknikal na dahilan, na itakda ang panahon ng validity ng certificate sa higit sa 24 na oras. Ang problemang ito ay higit na nalutas gamit ang ilang linya ng code sa dnscrypt-proxy: ang mga user ay makakatanggap ng babala na nagbibigay-impormasyon 30 araw bago mag-expire ang certificate, isa pang mensahe na may mas mataas na antas ng kalubhaan 7 araw bago mag-expire, at isang kritikal na mensahe kung ang certificate ay may natitira. bisa. wala pang 24 na oras. Nalalapat lamang ito sa mga sertipiko na sa una ay may mahabang panahon ng bisa.
Ang mga mensaheng ito ay nagbibigay sa mga user ng pagkakataong ipaalam sa mga operator ng DNS ang napipintong pag-expire ng certificate bago ito maging huli.
Marahil kung ang lahat ng mga gumagamit ng Firefox ay nakatanggap ng ganoong mensahe, kung gayon ang isang tao ay malamang na ipaalam sa mga developer at hindi nila papayagang mag-expire ang sertipiko. "Wala akong natatandaan na isang DNSCrypt server sa listahan ng mga pampublikong DNS server na nag-expire ang certificate nito sa nakalipas na dalawa o tatlong taon," isinulat ni Frank Denis. Sa anumang kaso, malamang na mas mabuting bigyan muna ng babala ang mga user kaysa i-disable ang mga extension nang walang babala.
Pinagmulan: www.habr.com