Yn y gorffennol, roedd tystysgrifau yn aml yn dod i ben oherwydd bod yn rhaid eu hadnewyddu Γ’ llaw. Yn syml, anghofiodd pobl ei wneud. Gyda dyfodiad Let's Encrypt a'r weithdrefn diweddaru awtomatig, mae'n ymddangos y dylid datrys y broblem. Ond diweddar yn dangos ei fod, mewn gwirionedd, yn dal yn berthnasol. Yn anffodus, mae tystysgrifau yn parhau i ddod i ben.
Rhag ofn ichi fethu'r stori, am hanner nos ar Fai 4, 2019, rhoddodd bron pob estyniad Firefox i ben yn sydyn i weithio.
Fel mae'n digwydd, digwyddodd y methiant enfawr oherwydd y ffaith bod Mozilla , a ddefnyddiwyd i arwyddo estyniadau. Felly, cawsant eu marcio fel βannilysβ ac ni chawsant eu gwirio (). Ar y fforymau, fel ateb, argymhellwyd analluogi dilysu llofnod estyniad i mewn am: ffurfweddu neu newid cloc y system.
Rhyddhaodd Mozilla y darn Firefox 66.0.4 yn brydlon, sy'n datrys y broblem gyda thystysgrif annilys, ac mae pob estyniad yn dychwelyd i normal. Mae'r datblygwyr yn argymell ei osod a dim atebion i osgoi dilysu llofnod oherwydd gallant wrthdaro Γ’'r clwt.
Fodd bynnag, mae'r stori hon unwaith eto yn dangos bod diwedd tystysgrif yn parhau i fod yn fater dybryd heddiw.
Yn hyn o beth, mae'n ddiddorol edrych ar ffordd eithaf gwreiddiol sut y deliodd datblygwyr y protocol Γ’'r dasg hon . Gellir rhannu eu datrysiad yn ddwy ran. Yn gyntaf, tystysgrifau tymor byr yw'r rhain. Yn ail, rhybuddio defnyddwyr am ddiwedd rhai hirdymor.
DNSCrypt
Mae DNSCrypt yn brotocol amgryptio traffig DNS. Mae'n amddiffyn cyfathrebiadau DNS rhag rhyng-gipiadau a MiTM, ac mae hefyd yn caniatΓ‘u ichi osgoi blocio ar lefel ymholiad DNS.
Mae'r protocol yn lapio traffig DNS rhwng cleient a gweinydd mewn lluniad cryptograffig, gan weithredu dros brotocolau trafnidiaeth y CDU a TCP. Er mwyn ei ddefnyddio, rhaid i'r cleient a'r datryswr DNS gefnogi DNSCrypt. Er enghraifft, ers mis Mawrth 2016, mae wedi'i alluogi ar ei weinyddion DNS ac yn y porwr Yandex. Mae sawl darparwr arall hefyd wedi cyhoeddi cefnogaeth, gan gynnwys Google a Cloudflare. Yn anffodus, nid oes llawer ohonynt (mae gweinyddwyr DNS 152 cyhoeddus wedi'u rhestru ar y wefan swyddogol). Ond y rhaglen gellir ei osod Γ’ llaw ar gleientiaid Linux, Windows a MacOS. Mae yna hefyd .
Sut mae DNSCrypt yn gweithio? Yn fyr, mae'r cleient yn cymryd allwedd gyhoeddus y darparwr a ddewiswyd ac yn ei ddefnyddio i wirio ei dystysgrifau. Mae'r allweddi cyhoeddus tymor byr ar gyfer y sesiwn a dynodwr y gyfres seiffr eisoes yno. Anogir cleientiaid i gynhyrchu allwedd newydd ar gyfer pob cais, ac anogir gweinyddwyr i newid allweddi bob 24 awr. Wrth gyfnewid allweddi, defnyddir yr algorithm X25519, ar gyfer arwyddo - EdDSA, ar gyfer amgryptio bloc - XSalsa20-Poly1305 neu XChaCha20-Poly1305.
Un o'r datblygwyr protocol Frank Denis bod ailosod awtomatig bob 24 awr wedi datrys problem tystysgrifau a ddaeth i ben. Mewn egwyddor, mae'r cleient cyfeirnod dnscrypt-proxy yn derbyn tystysgrifau gydag unrhyw gyfnod dilysrwydd, ond yn rhoi rhybudd "Mae cyfnod allwedd dnscrypt-proxy ar gyfer y gweinydd hwn yn rhy hir" os yw'n ddilys am fwy na 24 awr. Ar yr un pryd, rhyddhawyd delwedd Docker, lle gweithredwyd newid cyflym o allweddi (a thystysgrifau).
Yn gyntaf, mae'n hynod ddefnyddiol ar gyfer diogelwch: os yw'r gweinydd yn cael ei beryglu neu os yw'r allwedd yn cael ei ollwng, yna ni ellir dadgryptio traffig ddoe. Mae'r allwedd eisoes wedi newid. Mae hyn yn debygol o achosi problem ar gyfer gweithredu'r Gyfraith Yarovaya, sy'n gorfodi darparwyr i storio'r holl draffig, gan gynnwys traffig wedi'i amgryptio. Y goblygiad yw y gellir ei ddadgryptio yn ddiweddarach os oes angen trwy ofyn am yr allwedd o'r wefan. Ond yn yr achos hwn, ni all y wefan ei ddarparu, oherwydd ei fod yn defnyddio allweddi tymor byr, gan ddileu hen rai.
Ond yn bwysicaf oll, mae Denis yn ysgrifennu, mae allweddi tymor byr yn gorfodi gweinyddwyr i sefydlu awtomeiddio o'r diwrnod cyntaf. Os yw'r gweinydd yn cysylltu Γ’'r rhwydwaith ac nad yw'r sgriptiau newid allwedd wedi'u ffurfweddu neu ddim yn gweithio, bydd hyn yn cael ei ganfod ar unwaith.
Pan fydd awtomeiddio yn newid allweddi bob ychydig flynyddoedd, ni ellir dibynnu arno, a gall pobl anghofio bod tystysgrif yn dod i ben. Os byddwch chi'n newid yr allweddi bob dydd, bydd hyn yn cael ei ganfod ar unwaith.
Ar yr un pryd, os yw awtomeiddio wedi'i ffurfweddu'n normal, yna nid oes ots pa mor aml y caiff yr allweddi eu newid: bob blwyddyn, bob chwarter neu dair gwaith y dydd. Os bydd popeth yn gweithio am fwy na 24 awr, bydd yn gweithio am byth, yn ysgrifennu Frank Denis. Yn Γ΄l iddo, roedd yr argymhelliad o gylchdroi allwedd dyddiol yn ail fersiwn y protocol, ynghyd Γ’ delwedd Docker parod sy'n ei weithredu, yn lleihau nifer y gweinyddwyr Γ’ thystysgrifau sydd wedi dod i ben yn effeithiol, tra'n gwella diogelwch ar yr un pryd.
Fodd bynnag, roedd rhai darparwyr yn dal i benderfynu, am rai rhesymau technegol, i osod cyfnod dilysrwydd y dystysgrif i fwy na 24 awr. Cafodd y broblem hon ei datrys i raddau helaeth gydag ychydig linellau o god yn dnscrypt-proxy: mae defnyddwyr yn derbyn rhybudd gwybodaeth 30 diwrnod cyn i'r dystysgrif ddod i ben, neges arall gyda lefel difrifoldeb uwch 7 diwrnod cyn dod i ben, a neges hollbwysig os oes gan y dystysgrif unrhyw rai ar Γ΄l dilysrwydd, llai na 24 awr. Mae hyn ond yn berthnasol i dystysgrifau sydd Γ’ chyfnod dilysrwydd hir i ddechrau.
Mae'r negeseuon hyn yn rhoi cyfle i ddefnyddwyr roi gwybod i weithredwyr DNS bod tystysgrifau ar ddod i ben cyn ei bod hi'n rhy hwyr.
Efallai pe bai holl ddefnyddwyr Firefox yn derbyn neges o'r fath, yna mae'n debyg y byddai rhywun yn hysbysu'r datblygwyr ac ni fyddent yn caniatΓ‘u i'r dystysgrif ddod i ben. βNid wyf yn cofio un gweinydd DNSCrypt ar y rhestr o weinyddion DNS cyhoeddus y mae ei dystysgrif wedi dod i ben yn ystod y ddwy neu dair blynedd diwethaf,β ysgrifennodd Frank Denis. Beth bynnag, mae'n debyg ei bod yn well rhybuddio defnyddwyr yn gyntaf yn hytrach nag analluogi estyniadau heb rybudd.
Ffynhonnell: hab.com