| 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. Этого достаточно чтобы забеспокоиться.
| | |
| |
| 4.13, Аноним (-), 13:07, 24/03/2011 [^] [^^] [^^^] [ответить]
| –5 +/– |
Дык там же что угодно написать можно, он же не оригинальный а подмененный, челом сидящим на вашем канале.
| | |
| |
| 5.49, Одмин (?), 00:33, 25/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
нельзя, в сертификате от комодо будет написано что он от комодо.
| | |
| |
| 6.50, Аноним (-), 00:40, 25/03/2011 [^] [^^] [^^^] [ответить]
| –3 +/– |
на заборе тоже много че написано, а в реальности есть косяки, читайте ниже
| | |
| |
| 7.57, Michael Shigorin (ok), 21:14, 25/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Где именно ниже, а то уже много? Ну и написанное на заборе не валидируется по прибитому в браузере. (хотя... смотря как родители воспитали :)
| | |
|
|
|
|
|
|
| 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 +/– |
Если злоумышленник в состоянии вклинится в трафик жертвы, в самом начале, когда соединение еще не защищено, а соединение изначально не защищено, ключи получаются по незащищенному и могут быть подменены, как и запросы на их проверку, организовать прокси, то он может все.
| | |
| |
| 2.27, Аноним (-), 17:12, 24/03/2011 [^] [^^] [^^^] [ответить]
| –3 +/– |
Че минусовать то ? Неужели не очевидно что ключи, даже открытые, надо охранять ?
| | |
| |
| 3.62, Aleksey Salow (ok), 23:23, 27/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Школоло в криптографии не разбирается. Откуда им знать что против mitm работают только схемы с третьим доверенным лицом.
| | |
|
|
| 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 +/– |
Про предупреждение справедливости ради там ничего не сказано. Да хоть и так, во первых многие на это просто положат, как покладывают на предупреждения о самоподписанности, а во вторых, если мы перехватываем трафик клиента, то что нам запрещает не глушить а ответить на запрос о валидности утвердительно ?
| | |
| |
| 4.20, К.О. (?), 15:02, 24/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
То, что CRL тоже подписан ключом, которого у Тебя нет?
| | |
| |
| 5.24, Аноним (-), 16:43, 24/03/2011 [^] [^^] [^^^] [ответить]
| –2 +/– |
В том то и дело что есть, сессионный ключ которым все шифруется получается злоумышленником в начале соединения, злоумышленник садится посередине между клиентом и сервером и выступает для клиента как сервер, они обмениваются открытыми ключами и устанавливают честное с точки зрения клиента соединение. При необходимости злоумышленник также может общаться с сервером, выдавая себя за клиента. В результате имеем всю необходимую инфу.
| | |
| |
| 6.30, Аноним (-), 18:54, 24/03/2011 [^] [^^] [^^^] [ответить] | +2 +/– | Кроме подписи на CRL сертификате, которая делается секретным ключом удостоверяющ... большой текст свёрнут, показать | | |
| |
| 7.36, Аноним (-), 19:32, 24/03/2011 [^] [^^] [^^^] [ответить]
| –3 +/– |
Ничего там секретным ключом не шифруется, он используется только для расшифровки на принимающей стороне. Естественно если публичный ключ вшит (получен по закрытому каналу) то ничего не получится, но мы то какраз о получении публичных ключей по открытому каналу, протокол это позволяет и это используется, изначально вшито очень мало ключей, добавьте к этому использование самоподписанных, так что от m-in-m зачастую не спасает.
| | |
| |
| |
| 9.45, Аноним (-), 23:24, 24/03/2011 [^] [^^] [^^^] [ответить] | +/– | Не все вшито в браузер Не может он быть сразу раскрыт, проверка в удостоверяюще... текст свёрнут, показать | | |
|
|
|
| 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, рассматривать сертификат как недействительный". ;)
| | |
| |
| 4.23, Аноним (-), 16:31, 24/03/2011 [^] [^^] [^^^] [ответить]
| +/– |
А вот интересно что мешает устроить MITM атаку при обращении к 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 можно не травить, если правильно встать то все запросы будут идти через нас, тогда можно отвечать вместо любых абонентов и глушить лишнее.
| | |
| |
| 8.37, iZEN (ok), 21:52, 24/03/2011 [^] [^^] [^^^] [ответить] | +/– | Откуда ты это выдумал Закрытый ключ используется для генерации ПОДПИСИ открытог... текст свёрнут, показать | | |
| |
| 9.39, Аноним (-), 22:36, 24/03/2011 [^] [^^] [^^^] [ответить] | +/– | Ничего я не выдумал, это из описания протокола, пакеты закрытым ключом не шифрую... текст свёрнут, показать | | |
| |
| 10.41, Аноним (-), 22:44, 24/03/2011 [^] [^^] [^^^] [ответить] | +1 +/– | И как Вы подтвердите валидность Вашей открытой части подсунутого клиенту ключа ... текст свёрнут, показать | | |
| |
| |
| 12.43, iZEN (ok), 23:11, 24/03/2011 [^] [^^] [^^^] [ответить] | +/– | В браузер встроены не публичные ключи, а сертификаты с публичными ключами Серти... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 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 [^] [^^] [^^^] [ответить]
| +/– |
> Тут другая
> проблема, до тех пор пока ключики будут изначально распространяться по открытому
> каналу и самоподписываться дыра будет оставаться.
Вы сейчас о чём? Самоподписанный сертификат по определению не верен, его проверять не надо. О чём например все браузеры предупреждают.
| | |
| |
| 7.35, Аноним (-), 19:15, 24/03/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
Какраз о том что самоподписанный сертификат небезопасен, но их используют ;)
| | |
|
| 6.48, User294 (ok), 00:25, 25/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Предлагается что OCSP серверов будет несколько, все сразу не помрут.
Угу, с ауторитями что-то тоже предполагалось. Что они не будут помирать, что подписывать будут не что попало и не кому попало, etc.
> Тут другая проблема, до тех пор пока ключики будут изначально
> распространяться по открытому каналу и самоподписываться дыра будет оставаться.
Погодите, так если канал УЖЕ защищен и мы уверены в том что он именно с тем кем надо, тогда на кой черт нам еще раз проверять то что мы уже и так установили? Гарантии будут не сильнее чем гарантии по поводу шифрования исходного канала и уверенности в том что он - именно с тем с кем надо был установлен. Потому что если нас обманут на этой фазе - обманут по цепочке и на всех остальных, впарив левый сертификат, с левой инфо о том как его проверяить и прочая, что логично :)
| | |
| |
| 7.51, Аноним (-), 00:55, 25/03/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Угу, с ауторитями что-то тоже предполагалось.
Ну както эту проблему всеравно надо решать.
> Погодите, так если канал УЖЕ защищен...
Теоретически можно не проверять, но практически в этом нельзя быть уверенным, сертификаты даже в штатном режиме могут отзываться и т.п, поэтому надо перепроверять. А вот дальше самое интересное, насколько это надо делать жестко ? С одной стороны не переборщить с гемороем, трафиком, диктатурой и т.п, а с другой - убрать возможности подлома. Задачи прямопротивоположные и ни одна не решается идеально.
| | |
|
|
| 5.31, Frank (ok), 18:58, 24/03/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не иди в кассу, там тебе фальшивок всучат монетчики под видом работников банка.
Натуробмен наше всё!
| | |
| 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 ломают, сертификаты подписывают сами, вовремя не проверяют, протокол позволяет вольности, клиенты не реагируют должным образом и т.п.
| | |
| 6.53, User294 (ok), 07:32, 25/03/2011 [^] [^^] [^^^] [ответить] | +/– | Есть я, клиент Есть банк, сервер Все остальные по определению посторонние Чем... большой текст свёрнут, показать | | |
| |
| 7.56, iZEN (ok), 18:06, 25/03/2011 [^] [^^] [^^^] [ответить] | +/– | Почитай, что ли, об SSL-сертификатах и на чём держится протокол HTTPS OCSP-серв... большой текст свёрнут, показать | | |
| |
| 8.59, User294 (ok), 22:27, 25/03/2011 [^] [^^] [^^^] [ответить] | +/– | Я в курсе на чем он держится, спасибо OCSP не является обязательной частью А т... большой текст свёрнут, показать | | |
| |
| 9.60, iZEN (ok), 01:12, 26/03/2011 [^] [^^] [^^^] [ответить] | +/– | У Mozilla это делается перевыпуском версии браузера, в которой обновляется храни... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 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 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Статья подготовленна оперативно, но непрофессионально. Причем здесь перекрестная сертификация? Для её акуализации нужны аргументы весомее, чем нарушения элементарных политик безопасности центрами сертификации. Метод, которым получены эти отозванные сертификаты получены другим способом, а не тем, который описан Вами. Потому у поддельников нет шансов "вломать" таким же способом и корневые ЦС. А критика в адрес политики "Комодо" уже давно существует, только они ничего слушать не хотят, пока гром не грянет.
| | |
|
