En la pasinteco, atestiloj ofte eksvalidiĝis ĉar ili devis esti renovigitaj permane. Homoj simple forgesis fari ĝin. Kun la apero de Let's Encrypt kaj la aŭtomata ĝisdatigo procedo, ŝajnas, ke la problemo devus esti solvita. Sed lastatempa montras, ke ĝi fakte estas ankoraŭ grava. Bedaŭrinde, atestiloj daŭre eksvalidiĝas.
Se vi maltrafis la rakonton, je noktomezo la 4-an de majo 2019, preskaŭ ĉiuj Fajrovulpaj etendoj subite ĉesis funkcii.
Kiel ĝi rezultis, la amasa fiasko okazis pro la fakto, ke Mozilla , kiu estis uzata por subskribi etendaĵojn. Tial, ili estis markitaj kiel "nevalidaj" kaj ne estis kontrolitaj (). En la forumoj, kiel solvo, estis rekomendite malŝalti etendajn subskribajn konfirmon en pri: config aŭ ŝanĝante la sisteman horloĝon.
Mozilo rapide publikigis la diakilon Firefox 66.0.4, kiu solvas la problemon per nevalida atestilo, kaj ĉiuj etendaĵoj revenas al normalo. La programistoj rekomendas instali ĝin kaj neniuj solvoj por preteriri subskriban konfirmon ĉar ili povas konflikti kun la flikaĵo.
Tamen ĉi tiu rakonto denove montras, ke la eksvalidiĝo de atestilo restas urĝa afero hodiaŭ.
Ĉi-rilate, estas interese rigardi sufiĉe originalan manieron kiel la protokolaj programistoj traktis ĉi tiun taskon . Ilia solvo povas esti dividita en du partojn. Unue, ĉi tiuj estas mallongperspektivaj atestiloj. Due, avertante uzantojn pri la eksvalidiĝo de longdaŭraj.
DNSCrypt
DNSCrypt estas DNS-trafika ĉifrada protokolo. Ĝi protektas DNS-komunikadojn kontraŭ interkaptoj kaj MiTM, kaj ankaŭ ebligas al vi preterpasi blokadon ĉe la DNS-demandonivelo.
La protokolo envolvas DNS-trafikon inter kliento kaj servilo en ĉifrika konstruo, funkcianta super la UDP kaj TCP-transportprotokoloj. Por uzi ĝin, kaj la kliento kaj la DNS-solvilo devas subteni DNSCrypt. Ekzemple, ekde marto 2016, ĝi estas ebligita en siaj DNS-serviloj kaj en la retumilo Yandex. Pluraj aliaj provizantoj ankaŭ anoncis subtenon, inkluzive de Google kaj Cloudflare. Bedaŭrinde, ili ne estas multaj (152 publikaj DNS-serviloj estas listigitaj en la oficiala retejo). Sed la programo povas esti instalita permane sur Linukso, Vindozo kaj MacOS klientoj. Estas ankaŭ .
Kiel funkcias DNSCrypt? Resume, la kliento prenas la publikan ŝlosilon de la elektita provizanto kaj uzas ĝin por kontroli ĝiajn atestojn. La mallongperspektivaj publikaj ŝlosiloj por la sesio kaj la ĉifrosuit-identigilo jam estas tie. Klientoj estas kuraĝigitaj generi novan ŝlosilon por ĉiu peto, kaj serviloj estas instigitaj ŝanĝi ŝlosilojn ĉiujn 24 horojn. Dum interŝanĝado de ŝlosiloj, la algoritmo X25519 estas uzata, por subskribo - EdDSA, por bloka ĉifrado - XSalsa20-Poly1305 aŭ XChaCha20-Poly1305.
Unu el la protokolaj programistoj Frank Denis tiu aŭtomata anstataŭigo ĉiujn 24 horojn solvis la problemon de eksvalidiĝintaj atestiloj. Principe, la referenca kliento dnscrypt-proxy akceptas atestilojn kun ajna validecperiodo, sed eligas averton "La dnscrypt-proxy ŝlosilperiodo por ĉi tiu servilo estas tro longa" se ĝi validas dum pli ol 24 horoj. Samtempe, bildo de Docker estis publikigita, en kiu rapida ŝanĝo de ŝlosiloj (kaj atestiloj) estis efektivigita.
Unue, ĝi estas ege utila por sekureco: se la servilo estas endanĝerigita aŭ la ŝlosilo estas likita, tiam la hieraŭa trafiko ne povas esti deĉifrita. La ŝlosilo jam ŝanĝiĝis. Ĉi tio verŝajne kaŭzos problemon por la efektivigo de la Yarovaya Leĝo, kiu devigas provizantojn stoki la tutan trafikon, inkluzive de ĉifrita trafiko. La implico estas, ke ĝi poste povas esti deĉifrita se necese petante la ŝlosilon de la retejo. Sed en ĉi tiu kazo, la retejo simple ne povas provizi ĝin, ĉar ĝi uzas mallongperspektivajn ŝlosilojn, forigante malnovajn.
Sed plej grave, Denis skribas, mallongperspektivaj ŝlosiloj devigas servilojn agordi aŭtomatigon de la unua tago. Se la servilo konektas al la reto kaj la ŝlosilŝanĝaj skriptoj ne estas agorditaj aŭ ne funkcias, tio estos tuj detektita.
Kiam aŭtomatigo ŝanĝas ŝlosilojn ĉiujn kelkajn jarojn, oni ne povas fidi ĝin, kaj homoj povas forgesi pri la eksvalidiĝo de atestilo. Se vi ŝanĝas la ŝlosilojn ĉiutage, ĉi tio estos tuj detektita.
Samtempe, se aŭtomatigo estas agordita normale, tiam ne gravas kiom ofte la ŝlosiloj estas ŝanĝitaj: ĉiujare, ĉiun kvaronon aŭ tri fojojn tage. Se ĉio funkcias dum pli ol 24 horoj, ĝi funkcios eterne, skribas Frank Denis. Laŭ li, la rekomendo pri ĉiutaga klavrotado en la dua versio de la protokolo, kune kun preta Docker-bildo, kiu efektivigas ĝin, efike reduktis la nombron da serviloj kun eksvalidiĝintaj atestiloj, samtempe plibonigante sekurecon.
Tamen, iuj provizantoj ankoraŭ decidis, pro iuj teknikaj kialoj, agordi la validecperiodon de atestilo al pli ol 24 horoj. Ĉi tiu problemo estis plejparte solvita per kelkaj linioj de kodo en dnscrypt-proxy: uzantoj ricevas informan averton 30 tagojn antaŭ ol la atestilo eksvalidiĝas, alian mesaĝon kun pli alta severecnivelo 7 tagojn antaŭ eksvalidiĝo, kaj kritikan mesaĝon se la atestilo havas reston. valideco.malpli ol 24 horoj. Ĉi tio validas nur por atestiloj, kiuj komence havas longan validecperiodon.
Ĉi tiuj mesaĝoj donas al uzantoj la ŝancon informi DNS-funkciigistojn pri baldaŭa eksvalidiĝo de atestilo antaŭ ol estas tro malfrue.
Eble se ĉiuj uzantoj de Firefox ricevus tian mesaĝon, tiam iu verŝajne informus la programistojn kaj ili ne permesus al la atestilo eksvalidiĝi. "Mi ne memoras unu solan DNSCrypt-servilon en la listo de publikaj DNS-serviloj, kiuj eksvalidiĝis sian atestilon en la lastaj du aŭ tri jaroj," skribas Frank Denis. Ĉiukaze, verŝajne estas pli bone averti uzantojn unue ol malŝalti etendaĵojn sen averto.
fonto: www.habr.com