13.06 // Плановое июньское обновление SSL-сертификата сайта
В ближайшее время будет произведена замена SSL-сертификата. Обращаю внимание, что по многочисленным просьбам трудящихся было решено перейти на услуги удостоверяющего центра StartSSL™, корневой сертификат которого присутствует в хранилищах большинства ОС/браузеров.
Отпечатки нового сертификата сайта и УЦ приведены ниже.
Интересные атаки. У меня есть секретные ключи сертификатов, я могу спуфить DNS, но перенаправить трафик куда надо не могу.
А как можно сверить отпечаток анонимного собеседника? Вообще, имелось ввиду что это надо для сверки тех же подписей сертификата.
Правда с телефоном не очень всё радужно: откуда мне знать как звучит голос SATtva? Есть у кого идеи?
Доверие к первому отпечатку наобум, далее все остальные ключи/информация должны быть заверены первым ключом. Иногда просят доказать доверие разными аккаунтами, которые нельзя легко создать заранее: например, выложить отпечаток в профиле на сайте или поменять что-то в профиле, параллельно скинуть отпечаток через скайп и почту т.д. Вероятность, что противник сможет подменить все эти каналы одновременно, мала.
Бойкий, красивый, чистый молодой мужской голос. Как у нормального некурящего и непьющего человека.
Спуфить DNS можно на стороне DNS-сервера. Секретный ключ может украсть админ.
В ИБ стараются исключить сразу весь класс атак, а не обосновывать реально ли эксплуатировать ту или иную дыру. Может и натяжки, но параноя есть параноя. /etc/hosts решает вопрос. DNSSEC скорее для случаев, когда в /etc/hosts всё не пропишешь, да и HTTPS нету.
У вас не атака, а абсолютно неадекватный искусственный список предположений, если бы да кабы. И защита совершенно неадекватная соответственно. Вместо одного замка предлагаете повесить два, которые дадут в сумме ровно тот же уровень надёжности.
Атаки связанные с кражей секретного ключа принципиально не решаются с помощью криптографии.
Вопрос когда противник имеет прямой физический доступ к серверу? Ну-ну.
Передайте unknown'у, что кража ключей никак не может быть нивелирована в криптографических протоколах, а то он не знает этого и потому пытался выработать решение на случай компрометации ключей DA. Кстати, как в воду глядел: некоторые DA в итоге-таки сломали, и, от греха подальше, разработчики решили экстренно сменить их ключи. Что произошло бы, если б взлом остался не раскрыт, можно только догадываться. Кажется(?), это после того инцидента ввели меры: ключ на сервере однонедельный, каждый раз продляется (или обновляется, уже не помню), основной же ключ вообще не хранится на DA-сервере.
P.S.: Я понимаю, что вы хотите сказать, ваши возражения тоже уместны, но вот так легко и полностью отвергать некоторую вещь, как заведомо не приносяющую пользы атакующему ни в каких сценариях слишком самонадеянно, имхо.
Вопрос 2: Умнее ли мы (в этом вопросе) их?
Но допущения всё же странные. Ведь если секретный ключ украден, то скорее всего система скомпрометирована и зачем разворачивать клон на другом айпи — непонятно.
А вы уверены, что оно им не для галочки и пиара? Кстати, они и отпечатки SSL-сертификата вроде не подписывают.
/comment51230:
Я запутался. Если unknown прав, когда говорит, что https позволяет заметить подмену IP, то это противоречит 1ому комментарию SATtva`ы. Я бы хотел всё-таки табличку, понятную простым и далёким от этих премудростей людям:
Варианты событий: XZ, XW, YZ и YW. Для XZ понятно, что ответ «-» (система уязвима). Равно и с YW понятно, что система неузявима (т.е. «+»). А вот ответ на варианты XW и ZY я не могу понять, подскажите. Вроде алгебра событий простая, вариантов не много.
Кстати, это интересные вопросы, причём оба :) Впрочем, всегда можно сказать, что основное доверие — софту на torproject.org, а он подписан PGP-ключами. Тем не менее, имхо, отпечатки сервера им тоже стоило бы подписать.
XW: если противник не имеет секретного ключа сертификата, то вы в безопасности. Но если не будете сверять фингерпринт сертификата, то возможна подмена на сертификат, подписанный одним из CA, которому доверяет браузер.
YZ: угнали секретный ключ, но не имеют возможности подменить днс (в условиях статического айпи). Не уязвимо, если нет возможности произвести MITM на уровне провайдера.
Вообще, ИМХО, атаки такого рода не имеют смысла. Если это спецслужба, то она просто придёт к хостеру и в реальном времени будет делать то, что ей надо. Если по какой-то фантастической причине кто-то угнал сертификат, то заспуфить днс ещё постараться надо.
У него уже рут, зачем ему что-то ещё поднимать?
Рут у него сейчас есть, а завтра может не стать :)
* Если нет MITM между пользователем и сайтом.
** Если производится сверка фингерпринта сертификата.
** Если есть MITM, то должна производиться сверка фингерпринта сертификата.
Открытый ключ сервера не обязательно хранится у клиента, он в основном передаётся им самим при установке соединия, проверяется только подпись CA. В первую очередь браузер закричит, если ему подсунут сертификат с неправильным CN. Т.е. вы хотите зайти на сайт pgpru.com, атакующий подменил DNS-записи так, что вы перешли на его сервер, но у него нет сертификата, где CN=pgpru.com. Если сертификат поддельный, но CN правильный (такое возможно в случае кражы секретного ключа CA, либо при злонамеренных действиях CA), то спасут только либо дополнения типо Certificate Patrol, либо удаление всех CA из браузера с ручным добавлением каждого сертификата.
Да, и не должны, совершенно нормальная операция при смене хостинга, например. Или когда производится DNS-балансировка.
Если заметят, тогда и соответствующие меры примут. Полная переустановка системы и замена всех секретных ключей, имеющихся на сервере, в первую очередь.
С трудом вспоминаю какие-то старые кулхацкерские статьи, где утверждалось, что можно заспуфить клиента, если физически сидишь с ним в его же локалке. Правда, там скорее шла речь о спуфинге авторизации у провайдера (насмотря на имеющийся HTTPS), т.е. один клиент в локалке окучивает другого на предмет того, что он и есть провайдер, где надо авторизовываться. Как там было с подписями сертификатов, уже не помню, а спуфинг делался просто массовой рассылкой определённых пакетов (типа инфицировать его ARP-кэш или что-то в том духе).
P.S.: Спасибо за обстоятельный ответ, сейчас всё стало понятно.