| 1.1, Аноним (-), 12:11, 24/03/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +3 +/– | |
Для защиты от подмены сертификатов есть хорошее расширение для Firefox - Certificate Patrol. Оно хранит базу сертификатов посещенных сайтов и в случае изменения сертификата выводит окно, где выведены старый и новый сертификат.
К сожалению, этот аддон не совместим пока с только вышедшей 4 версией Лисы.
| | |
| |
| 2.7, Аноним (-), 12:32, 24/03/2011 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –1 +/– |
Вы думаете народ при этом станет звонить в ЦС и уточнять правда ли у них изменился сертификат ? И это не защищает от подмены сертификата при изначальном его получении.
| | |
| |
| 3.11, Аноним (-), 13:01, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Звонить не обязательно. К примеру было бы видно, что гугловский сертификат выдан вместо thawte теперь comodo. Этого достаточно чтобы забеспокоиться.
| | |
|
|
| 1.3, Аноним (-), 12:15, 24/03/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +1 +/– |
Открытая децентрализованная p2p валидация. Систему можно будет свалить только при условии внедрения взломанного кода в бОльшую часть узлов сети, что гораздо сложнее в условиях открытости кода.
| | |
| |
| 2.10, Аноним (-), 12:42, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
+ соединение по изначально защищенному каналу, т.е. хранить на клиенте закрытый ключ а получать его первично по др. каналу.
| | |
| |
| 3.15, Анонимиус (?), 13:40, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– | |
Выше отпостившим авторам и по тексту новости.
Вам не кажется, что немного теряется смысл самих сертификатов, при их постоянной проверке онлайн-средствами? ;) Тогда уж можно просто пользовать те или иные протоколы аутентификации, вероятно, также на основе ассиметричной криптографии, но это уже будет немного не тот "сертификат".
| | |
| |
| 4.18, Аноним (-), 14:00, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
Так и есть. С одной стороны понятно что идеальной защиты все равно не добиться, терморектальный криптоанализ никто не отменял, с другой понятно что усиливать защиту все равно надо.
Если сертификаты и инициация по открытому каналу, при ситуации "человек в середине", то по моему усиление возможно только запутыванием, но в принципе подлом всегда остается возможен обратным распутыванием, чисто технически, без социальной инженерии и терморектальностей.
А вот если распределенная сеть валидации то уже гораздо сложнее, тем более если инициация изначально закрыта, тут без социальной инженерии и терморектальностей уже не обойтись.
| | |
| 4.63, Aleksey Salow (ok), 23:25, 27/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 сертификаты используются не только в web-е, а и много где за пределами. Так зачем ломать рабочую инфраструктуру, да и проблема то не в сертификатах.
| | |
|
|
|
| 1.4, Аноним (-), 12:17, 24/03/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –9 +/– |
Если злоумышленник в состоянии вклинится в трафик жертвы, в самом начале, когда соединение еще не защищено, а соединение изначально не защищено, ключи получаются по незащищенному и могут быть подменены, как и запросы на их проверку, организовать прокси, то он может все.
| | |
| 1.5, Иван Иванович Иванов (?), 12:27, 24/03/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +1 +/– | |
А о скольки таких breach'ах мы ещё не знаем, интересно?
Ведь пока один разработчик не раскопал эту проблему, просматривая commit'ы в Firefox/Chrome, никто даже и не заикнулся о проблеме.
| | |
| |
| 2.22, Аноним (-), 15:24, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– | |
> А о скольки таких breach'ах мы ещё не знаем, интересно?
О многих. А зачем Вам об этом знать? А для специалиста или интересующихся совершенно очевидно что удостоверяющий центр тоже может быть скомпрометирован, это же очевидно, там же тоже люди работают.
| | |
|
| 1.6, Александр (??), 12:30, 24/03/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +1 +/– | |
Может кто-нибудь пояснить как сочитаются:
"В ситуации когда злоумышленник в состоянии вклинится в трафик жертвы и подменить содержимое сайта, он с тем же успехом может блокировать проверочные CRL/OCSP запросы"
"В качестве одного из вариантов решения проблемы называется создание производителями браузеров собственных кэширующих OCSP-серверов"
Если злоумышленик в состоянии блокировать проверочные CRL/OCSP запросы, то какая разница сколько серверов блокировать? Ну создадут собственный кэширующий сервер, а злоумышленик и его заблокирует, где смысл?
| | |
| |
| 2.8, Аноним (-), 12:38, 24/03/2011 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
Смысл в усложнении, устроить злоумышленнику больший гемор, но в принципе в данном случае он конечно не особо большим получается.
| | |
| 2.12, Аноним (-), 13:07, 24/03/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– |
> Если злоумышленик в состоянии блокировать проверочные CRL/OCSP запросы, то какая разница
> сколько серверов блокировать? Ну создадут собственный кэширующий сервер, а злоумышленик
> и его заблокирует, где смысл?
Смысл в том, что у некоторых CA OCSP-сервисы безбожно глючат и в их временной недоступности нет ничего удивительного. Добавив независимый OCSP-сервис можно в случае недоступности сразу двух систем не просто игнорировать ошибку, а выводить по умолчанию предупреждение.
| | |
| |
| 3.14, Аноним (-), 13:21, 24/03/2011 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –2 +/– |
Про предупреждение справедливости ради там ничего не сказано. Да хоть и так, во первых многие на это просто положат, как покладывают на предупреждения о самоподписанности, а во вторых, если мы перехватываем трафик клиента, то что нам запрещает не глушить а ответить на запрос о валидности утвердительно ?
| | |
| |
| |
| 5.24, Аноним (-), 16:43, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
В том то и дело что есть, сессионный ключ которым все шифруется получается злоумышленником в начале соединения, злоумышленник садится посередине между клиентом и сервером и выступает для клиента как сервер, они обмениваются открытыми ключами и устанавливают честное с точки зрения клиента соединение. При необходимости злоумышленник также может общаться с сервером, выдавая себя за клиента. В результате имеем всю необходимую инфу.
| | |
| |
| |
| 7.36, Аноним (-), 19:32, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| –3 +/– |
Ничего там секретным ключом не шифруется, он используется только для расшифровки на принимающей стороне. Естественно если публичный ключ вшит (получен по закрытому каналу) то ничего не получится, но мы то какраз о получении публичных ключей по открытому каналу, протокол это позволяет и это используется, изначально вшито очень мало ключей, добавьте к этому использование самоподписанных, так что от m-in-m зачастую не спасает.
| | |
|
| 6.64, Aleksey Salow (ok), 23:53, 27/03/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> В том то и дело что есть, сессионный ключ которым все шифруется
> получается злоумышленником в начале соединения, злоумышленник садится посередине между
> клиентом и сервером и выступает для клиента как сервер, они обмениваются
> открытыми ключами и устанавливают честное с точки зрения клиента соединение. При
> необходимости злоумышленник также может общаться с сервером, выдавая себя за клиента.
> В результате имеем всю необходимую инфу.
Вы о чём? У сервера есть его pub/priv ключи и сертификат с pub ключём подписанным CA. В начале он формирует посылку для клиента (для DH, например), подписывает своим приватным ключём и высылает клиенту вместе с сертификатом. Клиент проверяет сертификат на валидность по всей цепочке или, хотябы, самый первый CA, сертификат от которого у него точно есть, принимает решение доверять сертификату или нет, и уже только потом проверяется подпись посылки и всё такое. Если кто-то вклинится в середину, то он отпадёт ещё на этапе проверки клиентом сертификата. Обратная посылка шифруется открытым ключём сервера, так что вклинившийся узнать сессионный ключ никак не может. Это всё, есно, работает только если мы доверяем CA, если же нет, то вся PKI, как уже сказали, разваливается к чертям.
| | |
|
|
|
| 3.17, iZEN (ok), 13:44, 24/03/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +2 +/– |
 Если OCSP-сервисы безбожно глючат, то нету никакой уверенности в достоверности сертификатов, и вся система PKI рассыпается как карточный домик.
В Firefox 4.0 по умолчанию сертификат считается валидным, если нет доступа к серверу OCSP. Это самая настоящая дыра в безопасности! В настройках Дополнительные -> Шифрование -> Настройки OCSP можно/нужно изменить это злосчастное умолчание, отметив галочку "При ошибке соединения с сервером OCSP, рассматривать сертификат как недействительный". ;)
| | |
| |
| |
| 5.25, Аноним (-), 16:56, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Если обмен первичными ключами идет по открытому каналу то ничто не мешает. А вот если ключи вы заранее получили по др. каналу то злоумышленник не сможет их подменить и соответственно расшифровать ваш обмен.
| | |
| |
| 6.29, Frank (ok), 18:51, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 Получить открытый ключ что сервера, что клиента, просто и... бесполезно! Пакеты, зашифрованные закрытыми ключами, расшифровать, имея только открытые, не получится. Нужно иметь закрытый ключ одной из сторон, а его ты не перехватишь потому что он не передаётся.
Единственный вариант - становится посредине (MiM) и шифровать самому, своим закрытым ключом, но для этого тебе потребуется заставить жертву считать тебя сервером - например, отравлением кэша ДНС сервера, используемого жертвой. Иначе жертва пойдёт устанавливать SSL соединение по айпи адресу настоящего сервера и у тебя опять обломится.
| | |
| |
| 7.34, Аноним (-), 19:12, 24/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
Приблизительно так, но проще. Во первых закрытыми ключами ничего не шифруют, нет смысла т.к. они не передаются и соответственно вообще никто не сможет расшифровать. Закрытыми ключами расшифровывают, то что зашифровано открытым ключом. Получать открытый ключ просто и очень полезно, все шифруется сессионным ключом а он формируется на основе открытых, соответственно став посередине можно перехватить открытую передачу открытого ключа и подсунуть вместо него свой, на основе этого ключа будет сформирован сессионный и далее мы сможем расшифровать все остальное. DNS можно не травить, если правильно встать то все запросы будут идти через нас, тогда можно отвечать вместо любых абонентов и глушить лишнее.
| | |
|
|
|
| 4.26, User294 (ok), 17:08, 24/03/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| –1 +/– |
 > В Firefox 4.0 по умолчанию сертификат считается валидным, если нет доступа к
> серверу OCSP. Это самая настоящая дыра в безопасности!
А теперь прикинь, OCSP сервер взял да и умер. Ну, умирают вот иногда сервера. Даже самые хорошие, белые и пушистые. И это что, мне теперь по этому поводу без доступа в онлайн-банк чтоли остаться из-за даунайма ПОСТОРОННЕГО сервера? Мля, тогда банкоматом пользоваться наверное вообще не надо - там кардеры могли ридер привинтить в принципе. Поэтому надо самому дуть в отделение и получать бабло в кассе и никак иначе. К кассиру то ридер не привинтишь :)
| | |
| |
| 5.28, Аноним (-), 17:24, 24/03/2011 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –2 +/– |
Предлагается что OCSP серверов будет несколько, все сразу не помрут. Тут другая проблема, до тех пор пока ключики будут изначально распространяться по открытому каналу и самоподписываться дыра будет оставаться.
| | |
| |
| 6.32, Аноним (-), 19:00, 24/03/2011 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
> Тут другая
> проблема, до тех пор пока ключики будут изначально распространяться по открытому
> каналу и самоподписываться дыра будет оставаться.
Вы сейчас о чём? Самоподписанный сертификат по определению не верен, его проверять не надо. О чём например все браузеры предупреждают.
| | |
| 6.48, User294 (ok), 00:25, 25/03/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– | |
> Предлагается что OCSP серверов будет несколько, все сразу не помрут.
Угу, с ауторитями что-то тоже предполагалось. Что они не будут помирать, что подписывать будут не что попало и не кому попало, etc.
> Тут другая проблема, до тех пор пока ключики будут изначально
> распространяться по открытому каналу и самоподписываться дыра будет оставаться.
Погодите, так если канал УЖЕ защищен и мы уверены в том что он именно с тем кем надо, тогда на кой черт нам еще раз проверять то что мы уже и так установили? Гарантии будут не сильнее чем гарантии по поводу шифрования исходного канала и уверенности в том что он - именно с тем с кем надо был установлен. Потому что если нас обманут на этой фазе - обманут по цепочке и на всех остальных, впарив левый сертификат, с левой инфо о том как его проверяить и прочая, что логично :)
| | |
| |
| 7.51, Аноним (-), 00:55, 25/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> Угу, с ауторитями что-то тоже предполагалось.
Ну както эту проблему всеравно надо решать.
> Погодите, так если канал УЖЕ защищен...
Теоретически можно не проверять, но практически в этом нельзя быть уверенным, сертификаты даже в штатном режиме могут отзываться и т.п, поэтому надо перепроверять. А вот дальше самое интересное, насколько это надо делать жестко ? С одной стороны не переборщить с гемороем, трафиком, диктатурой и т.п, а с другой - убрать возможности подлома. Задачи прямопротивоположные и ни одна не решается идеально.
| | |
|
|
| 5.38, iZEN (ok), 22:05, 24/03/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> А теперь прикинь, OCSP сервер взял да и умер. Ну, умирают вот
> иногда сервера. Даже самые хорошие, белые и пушистые. И это что,
> мне теперь по этому поводу без доступа в онлайн-банк чтоли остаться
> из-за даунайма ПОСТОРОННЕГО сервера?
OCSP сервер не может быть посторонним. Он является структурообразующим PKI, ведущим актуальный список скомпрометированных сертификатов.
Клиентская программа на момент своего выпуска, как правило, уже имеет в своём составе хранилище доверенных сертификатов от тех сайтов, с которыми она должна работать по защищённому соединению. Но время идёт, сайты взламываются, подбираются пароли, узнаются секретные ключи владельцев защищённых сервисов. Когда это обнаруживается, центры сертификации (CA) отзывают сертификаты у взломанных сайтов и размещают списки потерявших валидность сертификатов на серверах OCSP (адреса серверов OCSP указываются в сертификатах, которые подписывает CA — по этим адресам клиентская программа определяет валидность сертификатов).
Клиентская программа, чтобы быть в курсе последних событий по конкретному сертификату, должна сначала обратиться к его серверу OCSP, чтобы проверить его валидность. Если сертификат отозван (заблокирован, нет возможности проверить подлинность и т.д.), то вычеркнуть его из хранилища доверенных сертификатов и не позволить пользователю работать с потерявшим доверие (скомпрометированным) сайтом.
> Мля, тогда банкоматом пользоваться наверное вообще
> не надо - там кардеры могли ридер привинтить в принципе. Поэтому
> надо самому дуть в отделение и получать бабло в кассе и
> никак иначе. К кассиру то ридер не привинтишь :)
Именно! А лучше за новым подписанным CA сертификатом банка, а старый скомпрометированный сертификат уничтожить.
| | |
| |
| 6.47, Аноним (-), 00:18, 25/03/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Это в идеале, а в реальности CA ломают, сертификаты подписывают сами, вовремя не проверяют, протокол позволяет вольности, клиенты не реагируют должным образом и т.п.
| | |
|
|
|
|
|
| 1.52, StrangeAttractor (ok), 01:31, 25/03/2011 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +1 +/– |
 > занесены в черные списки web-браузеров Firefox, Chrome/Chromium и Internet Explorer.
А Opera?
Я вот только сегодня товарищу, пользователю Opera, комп чистил от какой-то гадости, забившей в hosts на свой айпишник (к сожалению не подумал сохранить) все варианты Gmail и Yahoo и поднявшей на локалхосте прокси и перенаправившей браузеры через него.
| | |
| 1.65, Аноним (-), 18:25, 01/05/2011 [ответить] [﹢﹢﹢] [ · · · ] [к модератору]
| +/– |
Статья подготовленна оперативно, но непрофессионально. Причем здесь перекрестная сертификация? Для её акуализации нужны аргументы весомее, чем нарушения элементарных политик безопасности центрами сертификации. Метод, которым получены эти отозванные сертификаты получены другим способом, а не тем, который описан Вами. Потому у поддельников нет шансов "вломать" таким же способом и корневые ЦС. А критика в адрес политики "Комодо" уже давно существует, только они ничего слушать не хотят, пока гром не грянет.
| | |
|
