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

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

Както се оказа, масовият срив възникна заради факта, че на Mozilla изтече срокът на валидност на сертификата, който беше използван за подписване на добавките. Затова те бяха маркирани като „невалидни“ и не минаваха проверка (техническите детайли). На форумите като обходен вариант се препоръчваше да се изключи проверката на подписите на добавките в about:config или да се пренастроят системните часовници.

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

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

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

DNSCrypt

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

Протоколът опакова DNS трафика между клиента и сървъра в криптографска конструкция, работейки по транспортните протоколи UDP и TCP. За да го използват, както клиентът, така и DNS резолвера трябва да поддържат DNSCrypt. Например, от март 2016 година той беше активиран на своите DNS сървъри и в браузъра на „Яндекс“. Поддръжка обявиха и някои други доставчици, включително Google и Cloudflare. За съжаление, те не са много (на официалния сайт са изброени 152 публични DNS сървъра). Но програмата dnscrypt-proxy може да се инсталира ръчно на клиентите под 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-сървъри, който да е изтекъл за последните две или три години", пише Франк Денис. Във всеки случай, вероятно е по-добре първо да се предупредят потребителите, отколкото да се деактивират разширения без предупреждение.

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