В миналото сертификатите често изтичаха, защото трябваше да се подновяват ръчно. Хората просто са забравили да го направят. С появата на Let's Encrypt и процедурата за автоматично актуализиране, изглежда, че проблемът трябва да бъде решен. Но скорошно История на Firefox показва, че всъщност все още е актуален. За съжаление сертификатите продължават да изтичат.

В случай, че сте пропуснали историята, в полунощ на 4 май 2019 г. почти всички разширения на Firefox изведнъж спряха да работят.

Както се оказа, масовият провал се дължи на факта, че Mozilla сертификатът е изтекъл, който се използва за подписване на разширения. Следователно те бяха маркирани като „невалидни“ и не бяха проверени (технически подробности). Във форумите, като заобиколно решение, беше препоръчано да се деактивира проверката на подписа на разширението в за: довереник или промяна на системния часовник.

Mozilla бързо пусна корекцията за Firefox 66.0.4, която решава проблема с невалиден сертификат и всички разширения се връщат към нормалното. Разработчиците препоръчват да го инсталирате и не използвай няма заобиколни решения за заобикаляне на проверката на подписа, защото може да са в конфликт с корекцията.

Тази история обаче още веднъж показва, че изтичането на сертификата остава неотложен проблем днес.

В тази връзка е интересно да разгледаме доста оригинален начин как разработчиците на протокола се справиха с тази задача DNSCrypt. Решението им може да се раздели на две части. Първо, това са краткосрочни сертификати. Второ, предупреждаване на потребителите за изтичане на дългосрочните.

DNSCrypt

DNSCrypt е протокол за криптиране на DNS трафик. Той защитава DNS комуникациите от прихващане и MiTM, а също така ви позволява да заобиколите блокирането на ниво DNS заявка.

Протоколът обгръща DNS трафика между клиент и сървър в криптографска конструкция, работеща през транспортните протоколи UDP и TCP. За да го използвате, както клиентът, така и DNS резолверът трябва да поддържат DNSCrypt. Например от март 2016 г. той е активиран на своите DNS сървъри и в браузъра Yandex. Няколко други доставчици също обявиха поддръжка, включително Google и Cloudflare. За съжаление, няма много от тях (152 публични DNS сървъра са изброени на официалния уебсайт). Но програмата dnscrypt-прокси може да се инсталира ръчно на Linux, Windows и MacOS клиенти. Също така има сървърни реализации.

Как работи DNSCrypt? Накратко, клиентът взема публичния ключ на избрания доставчик и го използва, за да провери своите сертификати. Краткосрочните публични ключове за сесията и идентификаторът на пакета за шифроване вече са там. Клиентите се насърчават да генерират нов ключ за всяка заявка, а сървърите се насърчават да променят ключовете на всеки 24 часа. При обмен на ключове се използва алгоритъмът X25519, за подписване - EdDSA, за блоково криптиране - XSalsa20-Poly1305 или XChaCha20-Poly1305.

Един от разработчиците на протокола Франк Денис пишетази автоматична подмяна на всеки 24 часа реши проблема с изтеклите сертификати. По принцип референтният клиент на dnscrypt-proxy приема сертификати с всякакъв период на валидност, но издава предупреждение „Периодът на ключ на dnscrypt-proxy за този сървър е твърде дълъг“, ако е валиден повече от 24 часа. В същото време беше пуснат Docker образ, в който беше реализирана бърза смяна на ключове (и сертификати).

Първо, той е изключително полезен за сигурността: ако сървърът е компрометиран или ключът е изтекъл, тогава вчерашният трафик не може да бъде дешифриран. Ключът вече е сменен. Това вероятно ще създаде проблем за прилагането на закона Yarovaya, който принуждава доставчиците да съхраняват целия трафик, включително криптиран трафик. Изводът е, че по-късно може да бъде дешифриран, ако е необходимо, като поискате ключа от сайта. Но в този случай сайтът просто не може да го предостави, защото използва краткосрочни ключове, изтривайки стари.

Но най-важното, пише Денис, краткосрочните ключове принуждават сървърите да настройват автоматизация от първия ден. Ако сървърът се свърже към мрежата и скриптовете за промяна на ключ не са конфигурирани или не работят, това ще бъде открито незабавно.

Когато автоматизацията променя ключовете на всеки няколко години, на нея не може да се разчита и хората могат да забравят за изтичането на сертификата. Ако сменяте ключовете ежедневно, това ще бъде засечено моментално.

В същото време, ако автоматизацията е конфигурирана нормално, тогава няма значение колко често се сменят ключовете: всяка година, на всяко тримесечие или три пъти на ден. Ако всичко работи повече от 24 часа, ще работи завинаги, пише Франк Денис. Според него препоръката за ежедневна ротация на ключове във втората версия на протокола, заедно с готов Docker образ, който го прилага, ефективно намалява броя на сървърите с изтекли сертификати, като същевременно подобрява сигурността.

Въпреки това, някои доставчици все пак решиха по технически причини да зададат срока на валидност на сертификата на повече от 24 часа. Този проблем беше до голяма степен решен с няколко реда код в dnscrypt-proxy: потребителите получават информационно предупреждение 30 дни преди изтичането на сертификата, друго съобщение с по-високо ниво на сериозност 7 дни преди изтичането и критично съобщение, ако сертификатът има останали валидност.по-малко от 24 часа. Това се отнася само за сертификати, които първоначално имат дълъг период на валидност.

Тези съобщения дават възможност на потребителите да уведомят DNS операторите за предстоящото изтичане на сертификата, преди да е станало твърде късно.

Може би ако всички потребители на Firefox получат такова съобщение, тогава някой вероятно ще информира разработчиците и те няма да позволят сертификатът да изтече. „Не си спомням нито един DNSCrypt сървър в списъка с публични DNS сървъри, чийто сертификат е изтекъл през последните две или три години“, пише Франк Денис. Във всеки случай вероятно е по-добре първо да предупредите потребителите, вместо да деактивирате разширенията без предупреждение.

Източник: www.habr.com