| 1.1, Marbleless (?), 17:17, 23/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>одного из центров сертификации
Какого именно, не известно? Если неизвестно, то почему, можно ведь отследить цепочку подписей?
| | |
| |
| 2.2, User294 (ok), 17:21, 23/03/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Написано же:
> Предполагается, что подобное стало возможным в результате компрометации
> центра сертификации Comodo (CA). | | |
|
| 1.3, Marbleless (?), 17:38, 23/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> центра сертификации Comodo (CA).
Да, вижу, что теперь уже написали.
Ну, Comodo - оно и есть Comodo. Плохо, что существующая система с глобальными интернет-нотариусами может привести к таким последствиям.
| | |
| |
| 2.5, Andrey Mitrofanov (?), 17:45, 23/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Да, вижу, что теперь уже написали.
Представь себе, и об этом:
> Плохо, что существующая система с глобальными интернет-нотариусами может привести к таким последствиям.
- этот самый "разработчик Tor" ioerror "уже написал". Длинно и разнообразно.
| | |
|
| 1.4, Andrey Mitrofanov (?), 17:41, 23/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> может быть больше, 8 выявлено в трафике сети Tor.
Разработчик Tor анализирова открытые источники (списки отозванных сертификатов по "интернетам") в поисках "очернённых" броузеростроителями _серийных _номеров сертификатов. Нашёл 8, по ним -- выдавший ЦА, перепродавца Комодовского "авторитета".
Никакого "трафика сети Tor", совсем.
Максимум: сказал, что аналогичные блэклисты-затычки для Tor ещё в разработке.
Все равно никакого "трафика Tor"....
>> получить поддельные SSL-сертификаты
И кстати, про $SUBJ: сертификаты-то настоящие B) , их "просто" удалось получить "кому-то не тому", насколько я ничего не понимаю.
| | |
| 1.11, xz (??), 19:27, 23/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
>В худшем случае данный инцидент может поставить >под угрозу сам принцип организации иерархии >удостоверяющих центров.
Принцип то гнилой,давно пора.
| | |
| |
| 2.21, iZEN (ok), 10:00, 24/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Принцип не гнилой. Гнилой сам подход к его реализации в некоторых клиентских программах и браузерах, когда по умолчанию сертификаты ПРОХОДЯТ проверку при отсутствии доступа к серверу OCSP (серверу, содержащими список отозванных сертификатов). В частности, в Firefox 4.0 по умолчанию сертификат считается валидным, если нет доступа к серверу OCSP. В настройках Дополнительные -> Шифрование -> Настройки OCSP можно изменить это злосчастное умолчание, если взвести галочку "При ошибке соединения с сервером OCSP, рассматривать сертификат как недействительный". ;)
| | |
|
| 1.12, Аноним (-), 22:06, 23/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –11 +/– |
Принцип гнилой ? А сам протокол ? Я так понимаю если соединение устанавливается по открытому каналу, и на клиенте изначально нет секретного ключа, то сев на канал в момент установки соединения можно снять все исходные данные для дальнейшей расшифровки.
| | |
| |
| 2.14, Аноним (-), 01:10, 24/03/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ты того ... матчасть вначале изучи а потом уж на пол-мира позорься :)
| | |
| 2.15, Vitaly_loki (ok), 05:55, 24/03/2011 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Правильно, что разлогинился перед тем, как такой бред писать :) Почитай как работает ассиметричное шифрование.
- Клиент скачивает с сервера сертификат (открытый ключ).
- Потом клиент генерирует сеансовый ключ,
- Зашифровывает его открытым ключом (сертификатом). Расшифровать сеансовый ключ может ТОЛЬКО сервер (ибо только у него есть закрытая часть ключа).
- Сеансовый ключ отсылается серверу (отсылается он ЗАШИФРОВАННЫЙ открытым ключом).
Потом соединение шифруется уже сеансовым ключ. Итого, закрытый/открытый ключ нужен только для того чтоб обменяться сеансовым ключом
| | |
| |
| 3.19, zazik (ok), 09:46, 24/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Правильно, что разлогинился перед тем, как такой бред писать :) Почитай как
> работает ассиметричное шифрование.
> - Клиент скачивает с сервера сертификат (открытый ключ).
> - Потом клиент генерирует сеансовый ключ,
> - Зашифровывает его открытым ключом (сертификатом). Расшифровать сеансовый ключ может
> ТОЛЬКО сервер (ибо только у него есть закрытая часть ключа).
> - Сеансовый ключ отсылается серверу (отсылается он ЗАШИФРОВАННЫЙ открытым ключом).
> Потом соединение шифруется уже сеансовым ключ. Итого, закрытый/открытый ключ нужен только
> для того чтоб обменяться сеансовым ключом
Может быть он наслушался про MIM и неправильно себе представляет эту атаку?
| | |
| 3.24, Аноним (-), 11:17, 24/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Дык читал, и дырку вижу, хотя может просто чего то и недопонял, вы не кипешуйте так, если объясните в чем я не прав и чего не понимаю то буду вам весьма благодарен.
Мы посередине. Значит в начале можем вместо сертификата сервера подсунуть клиенту свой (самоподписанность также обходится), и соответственно расшифровать его запрос, т.к. алгоритм формирования сеансового ключа известен и закрытая часть ключа у нас есть. Далее расшифровав клиентский запрос мы формируем и отправляем серверу свой запрос, как будто мы изначальный клиент, и далее действуем как прокси, ну и собственно все.
| | |
| |
| 4.25, Vitaly_loki (ok), 11:36, 24/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
А-а-, дак вы имеете в виду Man-In-the- Middle атаку. Ну дак и в чем тут гнилость протокола? Если вы предоставили клиенту КОРРЕКТНЫЙ сертификат, подменили DNS-запись, то какие претензии к протоколу то? Может это DNS гнилой? :) Или ARP? :) По-вашему получается гнилое все ассиметричное шифрование, как класс.
| | |
| 4.28, filosofem (ok), 12:31, 24/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Все так. Поэтому и существуют CA, чьи сертификаты распространяются вместе с браузером и которые подтверждают аутентичность сертификата сервера.
В чем гнилость протокола и какие есть еще варианты?
| | |
|
| 3.29, . (?), 13:24, 04/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
сценарий такой только при использовании rsa; возможен также вариант с diffie-hellman
| | |
|
|
| 1.16, CHERTS (??), 08:49, 24/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Недавно отказался от получения сертификата от COMODO и видать правильно, если их корневой сертификат был скомпрометирован.
| | |
| 1.22, Аноним (-), 10:22, 24/03/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Вот мне интерестно почему у Comodo не вызвало подозрение то, что ВНЕЗАПНО одновременно гуглу, яху, скайпу и мозилле понадобились сертификаты?
| | |
| |
| 2.23, vadiml (ok), 10:39, 24/03/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Они же не вручную создаются.
Пришёл заказ -> снялись деньги -> поставилась подпись
Люди обычно смотрят когда что-то стопорится, идёт не так.
| | |
| |
| 3.27, TiGR (?), 11:57, 24/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это понятно, но система же должна реагировать как-то, когда на домен, для которого есть существующий и действенный сертификат хотят получить новый. Тут должна происходить какая-то подстраховка.
| | |
|
|
|
