id: Гость   вход   регистрация
текущее время 03:41 29/03/2024
Владелец: SATtva (создано 13/06/2012 21:04), редакция от 13/06/2012 21:04 (автор: SATtva) Печать
Категории: сайт проекта, стандарты, x.509, ssl
https://www.pgpru.com/Новости/2012/ПлановоеИюньскоеОбновлениеSSL-сертификатаСайта
создать
просмотр
редакции
ссылки

13.06 // Плановое июньское обновление SSL-сертификата сайта


В ближайшее время будет произведена замена SSL-сертификата. Обращаю внимание, что по многочисленным просьбам трудящихся было решено перейти на услуги удостоверяющего центра StartSSL™, корневой сертификат которого присутствует в хранилищах большинства ОС/браузеров.


Отпечатки нового сертификата сайта и УЦ приведены ниже.



 
На страницу: 1, 2, 3, 4, 5, 6 След.
Комментарии [скрыть комментарии/форму]
— Гость (18/06/2012 20:02)   <#>
то же самое касается и рядового админа мастерхоста
Админ мастерхоста не может дампить и вмешиваться в трафик сайта, расположенного на подконтрольной ему площадке?

широкий класс эффективных и простых атак
Интересные атаки. У меня есть секретные ключи сертификатов, я могу спуфить DNS, но перенаправить трафик куда надо не могу.

Ключу анонимного собеседника SATtva всё равно должен будет доверять почти наобум.
А как можно сверить отпечаток анонимного собеседника? Вообще, имелось ввиду что это надо для сверки тех же подписей сертификата.
Правда с телефоном не очень всё радужно: откуда мне знать как звучит голос SATtva? Есть у кого идеи?
— Гость (18/06/2012 20:23)   <#>
А как можно сверить отпечаток анонимного собеседника?

Доверие к первому отпечатку наобум, далее все остальные ключи/информация должны быть заверены первым ключом. Иногда просят доказать доверие разными аккаунтами, которые нельзя легко создать заранее: например, выложить отпечаток в профиле на сайте или поменять что-то в профиле, параллельно скинуть отпечаток через скайп и почту т.д. Вероятность, что противник сможет подменить все эти каналы одновременно, мала.

откуда мне знать как звучит голос SATtva? Есть у кого идеи?

Бойкий, красивый, чистый молодой мужской голос. Как у нормального некурящего и непьющего человека.
— Гость (18/06/2012 20:27)   <#>
У меня есть секретные ключи сертификатов, я могу спуфить DNS, но перенаправить трафик куда надо не могу.

Спуфить DNS можно на стороне DNS-сервера. Секретный ключ может украсть админ.

В ИБ стараются исключить сразу весь класс атак, а не обосновывать реально ли эксплуатировать ту или иную дыру. Может и натяжки, но параноя есть параноя. /etc/hosts решает вопрос. DNSSEC скорее для случаев, когда в /etc/hosts всё не пропишешь, да и HTTPS нету.
— Гость (18/06/2012 20:38)   <#>
Не к добру ТАКОЕ обновление. ZOG не дремлет.
— Гость (18/06/2012 21:14)   <#>
Секретный ключ может украсть админ.
Какой админ? Почему он не может украсть и секретный ключ DNSSEC? Почему вы допускаете кражу ключа, спуфинг на стороннем DNS-сервере, а провайдер белый и пушистый? Почему вы вообще используете не провайдерский DNS? DNS-запросы идут в открытом виде, почитайте спецификацию. Любой узел посередине может производить спуфинг.
У вас не атака, а абсолютно неадекватный искусственный список предположений, если бы да кабы. И защита совершенно неадекватная соответственно. Вместо одного замка предлагаете повесить два, которые дадут в сумме ровно тот же уровень надёжности.

В ИБ стараются исключить сразу весь класс атак
Атаки связанные с кражей секретного ключа принципиально не решаются с помощью криптографии.

/etc/hosts решает вопрос
Вопрос когда противник имеет прямой физический доступ к серверу? Ну-ну.
— Гость (18/06/2012 22:19)   <#>
Почему он не может украсть и секретный ключ DNSSEC?
Я не разбирался, где хранится DNSSEC-ключ. Разве наличие подписи публичным ключом — не статический факт? Нельзя подписать нечто и выложить подпись, но не сам ключ? К примеру, с SSL-сертификатами нельзя, т.к. сервер должен иметь доступ к приватному ключу для расшифровки файла, но приватный DNSSEC-ключ ему зачем?

Атаки связанные с кражей секретного ключа принципиально не решаются с помощью криптографии.
Передайте unknown'у, что кража ключей никак не может быть нивелирована в криптографических протоколах, а то он не знает этого и потому пытался выработать решение на случай компрометации ключей DA. Кстати, как в воду глядел: некоторые DA в итоге-таки сломали, и, от греха подальше, разработчики решили экстренно сменить их ключи. Что произошло бы, если б взлом остался не раскрыт, можно только догадываться. Кажется(?), это после того инцидента ввели меры: ключ на сервере однонедельный, каждый раз продляется (или обновляется, уже не помню), основной же ключ вообще не хранится на DA-сервере.

P.S.: Я понимаю, что вы хотите сказать, ваши возражения тоже уместны, но вот так легко и полностью отвергать некоторую вещь, как заведомо не приносяющую пользы атакующему ни в каких сценариях слишком самонадеянно, имхо.
— Гость (18/06/2012 23:05)   <#>
Сайт TorProject`а тоже поддерживает SSL (HTTPS), тем не менее они предпочли подписать свой домен через DNSSEC.
Вопрос 1: Зачем?
Вопрос 2: Умнее ли мы (в этом вопросе) их?
— Гость (18/06/2012 23:20)   <#>
Нельзя подписать нечто и выложить подпись, но не сам ключ?
Действительно, можно. Вот здесь пример использования.
Но допущения всё же странные. Ведь если секретный ключ украден, то скорее всего система скомпрометирована и зачем разворачивать клон на другом айпи — непонятно.

тем не менее они предпочли подписать свой домен через DNSSEC
А вы уверены, что оно им не для галочки и пиара? Кстати, они и отпечатки SSL-сертификата вроде не подписывают.
— Гость (18/06/2012 23:41)   <#>
/comment53570:
Это правда, что сертификат привязывает сайт не только к домменому имени, но и к конкретному IP?
SATtva: Нет.

/comment51230:
Если DNS-сервер начнёт фальсифицировать ответ, выдавая IP фишинговых сайтов вместо нужных, заметит ли это браузер? И тот же вопрос в случае https.
unknown: 1. Нет. 2. Да.
SATtva: Если фишинговый сайт озаботится достоверным SSL-сертификатом, то подмену можно и не заметить.

Я запутался. Если unknown прав, когда говорит, что https позволяет заметить подмену IP, то это противоречит 1ому комментарию SATtva`ы. Я бы хотел всё-таки табличку, понятную простым и далёким от этих премудростей людям:
Вариант атакиИмеетсяНе имеется
DNS spoofingXY
Кража SSL-сертификатаZW

Варианты событий: XZ, XW, YZ и YW. Для XZ понятно, что ответ «-» (система уязвима). Равно и с YW понятно, что система неузявима (т.е. «+»). А вот ответ на варианты XW и ZY я не могу понять, подскажите. Вроде алгебра событий простая, вариантов не много.

А вы уверены, что оно им не для галочки и пиара? Кстати, они и отпечатки SSL-сертификата вроде не подписывают.

Кстати, это интересные вопросы, причём оба :) Впрочем, всегда можно сказать, что основное доверие — софту на torproject.org, а он подписан PGP-ключами. Тем не менее, имхо, отпечатки сервера им тоже стоило бы подписать.
— Гость (19/06/2012 00:02)   <#>
если секретный ключ украден, то скорее всего система скомпрометирована и зачем разворачивать клон на другом айпи — непонятно.
Можно пофантазировать в духе: злостный взломщик получает root-доступ к pgpru.com, его сертификат, размещает свой фишинговый сайт и начинает активную слежку за его пользователями с целью деанонимизировать их или составить соцпортрет и т.д. Может, у меня плохая фатазия, и есть более реалистичные сценарии: например, сотрудники спецслужб делают то же самое, т.к. не могут добиться ордера, чтоб делать это же на самом сервере masterhost официально.
— Гость (19/06/2012 00:11)   <#>
Если unknown прав, когда говорит, что https позволяет заметить подмену IP
Он имел ввиду тот случай, когда у фишингого сайта нет секретного ключа сертификата/поддельного сертификата на нужный CN.

XW: если противник не имеет секретного ключа сертификата, то вы в безопасности. Но если не будете сверять фингерпринт сертификата, то возможна подмена на сертификат, подписанный одним из CA, которому доверяет браузер.
YZ: угнали секретный ключ, но не имеют возможности подменить днс (в условиях статического айпи). Не уязвимо, если нет возможности произвести MITM на уровне провайдера.

Вообще, ИМХО, атаки такого рода не имеют смысла. Если это спецслужба, то она просто придёт к хостеру и в реальном времени будет делать то, что ей надо. Если по какой-то фантастической причине кто-то угнал сертификат, то заспуфить днс ещё постараться надо.

злостный взломщик получает root-доступ к pgpru.com
У него уже рут, зачем ему что-то ещё поднимать?
— Гость (19/06/2012 00:36)   <#>
Он имел ввиду тот случай, когда у фишингого сайта нет секретного ключа
...
XW: если противник не имеет секретного ключа сертификата, то вы в безопасности.
Примерно понятно. Т.е. при фишинге DNS без владения валидным сертификатом (XW) фишер может перетянуть трафик на себя, но не сможет его расшифровать, потому атака вскроется. С другой стороны, если владелец HTTPS-сайта вдруг решит переехать на другой IP, то пользователи это непосредственно не смогут заметить (ни браузер не сообщит, ни аддоны к нему). Верно?

У него уже рут, зачем ему что-то ещё поднимать?
Рут у него сейчас есть, а завтра может не стать :)
— Гость (19/06/2012 01:05)   <#>
Вообще, по уму табличку надо делать так:
Имеется ли уязвимостьСпуфинг естьСпуфинга нет
Сертификат украден+*
Сертификат не украден*****

* Если нет MITM между пользователем и сайтом.
** Если производится сверка фингерпринта сертификата.
** Если есть MITM, то должна производиться сверка фингерпринта сертификата.

но не сможет его расшифровать
Открытый ключ сервера не обязательно хранится у клиента, он в основном передаётся им самим при установке соединия, проверяется только подпись CA. В первую очередь браузер закричит, если ему подсунут сертификат с неправильным CN. Т.е. вы хотите зайти на сайт pgpru.com, атакующий подменил DNS-записи так, что вы перешли на его сервер, но у него нет сертификата, где CN=pgpru.com. Если сертификат поддельный, но CN правильный (такое возможно в случае кражы секретного ключа CA, либо при злонамеренных действиях CA), то спасут только либо дополнения типо Certificate Patrol, либо удаление всех CA из браузера с ручным добавлением каждого сертификата.

С другой стороны, если владелец HTTPS-сайта вдруг решит переехать на другой IP, то пользователи это непосредственно не смогут заметить (ни браузер не сообщит, ни аддоны к нему). Верно?
Да, и не должны, совершенно нормальная операция при смене хостинга, например. Или когда производится DNS-балансировка.

а завтра может не стать
Если заметят, тогда и соответствующие меры примут. Полная переустановка системы и замена всех секретных ключей, имеющихся на сервере, в первую очередь.
— Гость (19/06/2012 01:07)   <#>
он в основном передаётся им самим
Читать как: он в основном передаётся самим сервером.
— Гость (08/07/2012 04:44)   <#>
YZ: угнали секретный ключ, но не имеют возможности подменить днс (в условиях статического айпи). Не уязвимо, если нет возможности произвести MITM на уровне провайдера.
Точнее было бы написать «MITM на канале между пользователем и сайтом», а будет ли это его провайдер, провайдер сайта, или какой-то хост посередине — уже дело третье.

Если по какой-то фантастической причине кто-то угнал сертификат, то заспуфить днс ещё постараться надо.
С трудом вспоминаю какие-то старые кулхацкерские статьи, где утверждалось, что можно заспуфить клиента, если физически сидишь с ним в его же локалке. Правда, там скорее шла речь о спуфинге авторизации у провайдера (насмотря на имеющийся HTTPS), т.е. один клиент в локалке окучивает другого на предмет того, что он и есть провайдер, где надо авторизовываться. Как там было с подписями сертификатов, уже не помню, а спуфинг делался просто массовой рассылкой определённых пакетов (типа инфицировать его ARP-кэш или что-то в том духе).

P.S.: Спасибо за обстоятельный ответ, сейчас всё стало понятно.
На страницу: 1, 2, 3, 4, 5, 6 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3