November 22nd, 2010

iao

SSL, N+1 часть марлезонского балета

Как я уже говорил, безопасность SSL при сегодняшней архитектуре и реализации -- это карточный домик. Но вы, наверное, думаете, что его, конечно, легко сломать, но легко и починить -- при потере доверия к любому удостоверяющему центру, сертификат отзывается на раз-два и мы все снова немножко живем счастливо.

Так вот, для тех, кто не читает securityblogru и пребывает на эту тему в счастливом заблуждении, у меня плохая новость весьма практического свойства, которую откопал ivlad и опубликовал там, если можно считать "новостью" пятилетней давности баян.

Собственно, вот она:

http://www.narus.com/index.php/news/industry-news/article/209

Для совсем ленивых перескажу: уже пять лет Narus, один из ведущих производителей средств "lawful interception" (СОРМ по-нашему), является партнером Verisign'а (которому сейчас совокупно принадлежит примерно половина мирового бизнеса коммерческих удостоверяющих центров и до кучи два корневых сервера DNS). Формально и официально услуги предоставляются только в одну сторону: Narus -- клиентам Verisign. Однако, кто может поручиться, что американское правительство не попросит эту сладкую парочку, если уже не попросило, осуществлять перехват SSL-трафика с помощью специально подписанных Verisign'ом сертификатов, конечно, с благой целью борьбы с международным терроризмом, педофилией и кровавой диктатурой? Что тогда?

А тогда вот что: Verisign -- это вовсе не хрен собачий. "Выкинуть" его из бизнеса невозможно -- собственно, этот бизнес строился так, чтобы у них всегда было на хлеб с маслом. Так что нам останется только сосать и глотать и делать вид, что ничего страшного не произошло, в конце концов, наша безопасность в добрых и надежных руках.

Собственно, и идея с "картографированием" существующих де факто отношений доверия оказывается бесполезной по очевидным причинам.

Нужны, получается, две вещи:

Во-первых, сертификат должен стать прямым аналогом pgp или ssh ключа. Любое изменение долнжо восприниматься софтом как угроза безопасности, для игнорирования которой необходимо совершить трудоемкое действие, во время которого у пользователя будет время хорошо подумать. Даже если новый сертификат подписан тем же удостоверяющим центром, что и старый и вообще это рутинная процедура обновления. Кстати, стандартной процедурой обновления должно быть получение нового сертификата по каналу, верифицированному старым.

Во-вторых, это собственно расширенное понимание "во-первых" -- нужна децентрализованная система кросс-сертификации с жестким разграничением границ полномочий каждого удостоверяющего центра. В рамках x509v3 все это вполне реализуемо.

Есть мысли накидать драфт для ietf и как это донести до конечного клиента? Судя по ситуации с веб-браузерами, их авторы вообще этому классу проблем не желают уделять внимание.
hand

Кодовый замок на квартиру в качестве основного и единственного?

Вот egorfine не побоялся. Я к затее поначалу отнесся скептически, но на второй взгляд она выглядит не такой глупой, как кажется на первый. Я ему там задал пару очевидных вопросов, ответы на них обнадеживают (учитывая, что ширпотребные механические замки ан масс полная туфта для человека с минимальными навыками по взлому). Есть еще что-то, о чем я не подумал? Если про denial of service, то и в замочную скважину можно клея налить. Надежность? Думаю, сравнима..