Во минатото, сертификатите често истекуваа бидејќи мораа рачно да се обновуваат. Луѓето едноставно заборавија да го направат тоа. Со доаѓањето на Let’s Encrypt и процедурата за автоматско ажурирање, се чини дека проблемот треба да се реши. Но неодамна покажува дека таа, всушност, сè уште е релевантна. За жал, сертификатите продолжуваат да истекуваат.
Во случај да ја пропуштивте приказната, на полноќ на 4 мај 2019 година, речиси сите екстензии на Firefox одеднаш престанаа да работат.
Како што се испостави, масовниот неуспех се случи поради фактот што Mozilla , што се користеше за потпишување екстензии. Затоа, тие беа означени како „невалидни“ и не беа потврдени (). На форумите, како заобиколување, беше препорачано да се оневозможи проверката на потписот на екстензијата за: конфиг или менување на системскиот часовник.
Mozilla брзо ја објави закрпата за Firefox 66.0.4, која го решава проблемот со неважечки сертификат и сите екстензии се враќаат во нормала. Програмерите препорачуваат да го инсталираат и нема решенија за заобиколување на верификацијата на потписот бидејќи тие може да бидат во конфликт со закрпата.
Сепак, оваа приказна уште еднаш покажува дека истекувањето на сертификатот останува актуелно прашање денес.
Во овој поглед, интересно е да се погледне прилично оригинален начин како развивачите на протокол се справија со оваа задача . Нивното решение може да се подели на два дела. Прво, ова се краткорочни сертификати. Второ, предупредување на корисниците за истекување на долгорочните.
DNSCrypt
DNSCrypt е протокол за шифрирање на сообраќај DNS. Ги штити DNS комуникациите од пресретнување и MiTM, а исто така ви овозможува да го заобиколите блокирањето на ниво на барање DNS.
Протоколот го обвива DNS сообраќајот помеѓу клиентот и серверот во криптографска конструкција, која работи преку протоколите за транспорт на UDP и TCP. За да го користите, и клиентот и решавачот на DNS мора да поддржуваат DNSCrypt. На пример, од март 2016 година, тој е овозможен на неговите DNS сервери и во прелистувачот Yandex. Неколку други провајдери, исто така, најавија поддршка, вклучувајќи ги Google и Cloudflare. За жал, нема многу од нив (152 јавни DNS сервери се наведени на официјалната веб-страница). Но, програмата може да се инсталира рачно на клиенти на Linux, Windows и MacOS. Исто така има .
Како работи DNSCrypt? Накратко, клиентот го зема јавниот клуч на избраниот провајдер и го користи за да ги потврди неговите сертификати. Краткорочните јавни клучеви за сесијата и идентификаторот на пакетот шифри се веќе таму. Клиентите се охрабруваат да генерираат нов клуч за секое барање, а серверите се охрабруваат да ги менуваат клучевите на секои 24 часа. При размена на клучеви, се користи алгоритмот X25519, за потпишување - EdDSA, за шифрирање блок - XSalsa20-Poly1305 или XChaCha20-Poly1305.
Еден од развивачите на протокол Френк Денис таа автоматска замена на секои 24 часа го реши проблемот со истечените сертификати. Во принцип, референтниот клиент dnscrypt-proxy прифаќа сертификати со кој било период на важност, но издава предупредување „Периодот на клучот за dnscrypt-proxy за овој сервер е премногу долг“ доколку е валиден повеќе од 24 часа. Во исто време, беше објавена слика на Docker, во која беше спроведена брза промена на клучевите (и сертификатите).
Прво, тој е исклучително корисен за безбедност: ако серверот е компромитиран или клучот е протечен, тогаш вчерашниот сообраќај не може да се дешифрира. Клучот е веќе променет. Ова најверојатно ќе претставува проблем за имплементацијата на Законот Јароваја, кој ги принудува провајдерите да го складираат целиот сообраќај, вклучувајќи го и шифрираниот сообраќај. Импликацијата е дека подоцна може да се дешифрира доколку е потребно со барање на клучот од страницата. Но, во овој случај, страницата едноставно не може да го обезбеди, бидејќи користи краткорочни клучеви, бришејќи ги старите.
Но, што е најважно, пишува Денис, краткорочните клучеви ги принудуваат серверите да постават автоматизација уште од првиот ден. Ако серверот се поврзе на мрежата и скриптите за промена на клучот не се конфигурирани или не работат, ова ќе се открие веднаш.
Кога автоматизацијата ги менува клучевите на секои неколку години, не може да се потпре на неа и луѓето можат да заборават на истекувањето на сертификатот. Ако ги менувате копчињата секојдневно, ова ќе се открие веднаш.
Во исто време, ако автоматизацијата е конфигурирана нормално, тогаш не е важно колку често се менуваат клучевите: секоја година, секоја четвртина или три пати на ден. Ако сè работи повеќе од 24 часа, ќе работи засекогаш, пишува Френк Денис. Според него, препораката за дневна ротација на клучеви во втората верзија на протоколот, заедно со готовата Docker слика што ја имплементира, ефективно го намалиле бројот на сервери со истечен сертификат, а истовремено ја подобрувале безбедноста.
Сепак, некои провајдери сепак одлучија, поради некои технички причини, да го постават периодот на важност на сертификатот на повеќе од 24 часа. Овој проблем беше во голема мера решен со неколку линии код во dnscrypt-proxy: корисниците добиваат информативно предупредување 30 дена пред истекот на сертификатот, друга порака со повисок степен на сериозност 7 дена пред истекот и критична порака ако сертификатот има преостанат важност.помалку од 24 часа. Ова се однесува само на сертификати кои првично имаат долг период на важност.
Овие пораки им даваат на корисниците можност да ги известат DNS операторите за претстојното истекување на сертификатот пред да биде предоцна.
Можеби ако сите корисници на Firefox добијат таква порака, тогаш некој веројатно би ги известил програмерите и тие нема да дозволат да истече сертификатот. „Не се сеќавам на ниту еден DNSCrypt сервер на списокот на јавни DNS сервери на кој му истекол сертификатот во последните две или три години“, пишува Френк Денис. Во секој случај, веројатно е подобро прво да ги предупредите корисниците, наместо да ги оневозможите екстензиите без предупредување.
Извор: www.habr.com