https://m.opennet.dev/openforum/vsluhforumID3/75727.html Компания Comodo, спустя восемь дней с момента обнаружения проблемы, опубликовала заявление (http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html) в котором обобщила суть инцидента, в результате которого злоумышленникам удалось получить девять валидных HTTPS-сертификатов для ряда известных web-ресурсов. Используя данные сертификаты злоумышленники могли сформировать поддельный сайт, который был бы неотличим от настоящего и содержал не вызывающий подозрение SSL-сертификат. Перенаправить пользователя на подобные сайты можно используя, например, атаки man-in-middle (http://ru.wikipedia.org/wiki/%D0%A7%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D0%BA_%D0%BF%D0%BE%D1%81%D0%B5%D1%80%D0%B5%D0%B4%D0%B8%D0%BD%D0%B5) или отравление DNS-кэша. <br><br><br><br>По данным Comodo, 9 обманных сертификатов злоумышленникам удалось сгенерировать в результате взлома пользовательского аккаунта в одного из доверенных регистрирующих центров (RA, Registration Authority). Инфраструктура удостоверяющего центра (CA (http://ru.wi...<br><br>URL: http://www.com https://m.opennet.dev/openforum/vsluhforumID3/75727.html#65 Sun, 01 May 2011 14:25:32 GMT Статья подготовленна оперативно, но непрофессионально. Причем здесь перекрестная сертификация? Для её акуализации нужны аргументы весомее, чем нарушения элементарных политик безопасности центрами сертификации. Метод, которым получены эти отозванные сертификаты получены другим способом, а не тем, который описан Вами. Потому у поддельников нет шансов "вломать" таким же способом и корневые ЦС. А критика в адрес политики "Комодо" уже давно существует, только они ничего слушать не хотят, пока гром не грянет. <br> https://m.opennet.dev/openforum/vsluhforumID3/75727.html#64 Sun, 27 Mar 2011 19:53:09 GMT &gt; В том то и дело что есть, сессионный ключ которым все шифруется <br>&gt; получается злоумышленником в начале соединения, злоумышленник садится посередине между <br>&gt; клиентом и сервером и выступает для клиента как сервер, они обмениваются <br>&gt; открытыми ключами и устанавливают честное с точки зрения клиента соединение. При <br>&gt; необходимости злоумышленник также может общаться с сервером, выдавая себя за клиента. <br>&gt; В результате имеем всю необходимую инфу.<br><br>Вы о чём? У сервера есть его pub/priv ключи и сертификат с pub ключём подписанным CA. В начале он формирует посылку для клиента (для DH, например), подписывает своим приватным ключём и высылает клиенту вместе с сертификатом. Клиент проверяет сертификат на валидность по всей цепочке или, хотябы, самый первый CA, сертификат от которого у него точно есть, принимает решение доверять сертификату или нет, и уже только потом проверяется подпись посылки и всё такое. Если кто-то вклинится в середину, то он отпадёт ещё на этапе проверки клиентом сертификата. Обратная посы https://m.opennet.dev/openforum/vsluhforumID3/75727.html#63 Sun, 27 Mar 2011 19:25:34 GMT сертификаты используются не только в web-е, а и много где за пределами. Так зачем ломать рабочую инфраструктуру, да и проблема то не в сертификатах.<br> https://m.opennet.dev/openforum/vsluhforumID3/75727.html#62 Sun, 27 Mar 2011 19:23:13 GMT Школоло в криптографии не разбирается. Откуда им знать что против mitm работают только схемы с третьим доверенным лицом.<br> https://m.opennet.dev/openforum/vsluhforumID3/75727.html#61 Sat, 26 Mar 2011 09:58:56 GMT &gt; Если программа не может подтвердить легитимность сертификата то она не должна давать пользователю права совершать транзакцию<br><br>Ну так вот и получается, если сторонний OCSP сервер оказался в дауне по внутренним причинам, задосили, скомпроментировали, роутер сбойнул, и т.п, то наша организация сразу атакуется толпой хомяков, теряет клиентов, а потом этой толпой атакуется OCSP сервер, если поднимется. Представьте что по этому принципу начнет работать не ноль целых хренадцать десятых, а большая часть сайтов. Далеко не всегда как вы говорите возможно организовать соответствующую архитектуру, а терять клиентов никому не хочется, по этому и сделали возможность отложенной проверки, а она повлекла возможность подлома.<br> https://m.opennet.dev/openforum/vsluhforumID3/75727.html#60 Fri, 25 Mar 2011 22:12:47 GMT &gt;&gt; OCSP-сервер является важным дополнительным средством подтверждения подлинности сертификата <br>&gt; По-моему, фичу блеклиста можно сделать и менее через анус.<br><br>У Mozilla это делается перевыпуском версии браузера, в которой обновляется хранилище сертификатов CA. Либо включением обязательно проверки актуальности сертификатов в настройках устаревшей версии браузера, как я написал.<br><br>&gt; А вот если банковская транзакция сорвется только потому что по OCSP не смогли достукаться до сервера - это будет не прикольно.<br>&gt; Частота отказов вырастет в РАЗЫ, если это будет поводом не проводить транзакцию вообще.<br><br>Ещё один повод банку задуматься о поддержке инфраструктуры защищённых транзакций. С ломаемой, не выдерживающей натиска инфраструктурой никто связываться не захочет, с банком её имеющей &#8212; тем более!<br><br>&gt; А то если сбойнет роутер по пути - очевилно, <br>&gt; пакеты доставлены не будут и соединиться с OCSP сервером я не <br>&gt; смогу. Если это будет поводом убить сертификат, как ты предлагал - <br>&gt; я, очевдно, на раз лишус https://m.opennet.dev/openforum/vsluhforumID3/75727.html#59 Fri, 25 Mar 2011 19:27:58 GMT &gt; Почитай, что ли, об SSL-сертификатах и на чём держится протокол HTTPS.<br><br>Я в курсе на чем он держится, спасибо. OCSP не является обязательной частью. А ты предлагаешь аж прибивать сертификаты если он не сработает. Спасибо, елки. Этак любой даунтайм сетевого оборудования будет вызывать столпотворения в банках. <br><br>&gt; OCSP-сервер является важным дополнительным средством подтверждения подлинности сертификата <br><br>По-моему, фичу блеклиста можно сделать и менее через анус. Например как БД плохих парней у мозиллы, так что единичный неконект к серверу вообше ничего не даст кроме возможно устаревания БД плохих парней на некий не сильно большой срок. А вот если банковская транзакция сорвется только потому что по OCSP не смогли достукаться до сервера - это будет не прикольно. Частота отказов вырастет в РАЗЫ, если это будет поводом не проводить транзакцию вообще. <br><br>&gt; и его срока действия, что увеличивает защищённость транзакций, но никак не <br>&gt; уменьшает.<br><br>Все хорошо в меру. А то так можно дойти до того что тебя (для https://m.opennet.dev/openforum/vsluhforumID3/75727.html#58 Fri, 25 Mar 2011 18:20:25 GMT &gt; Натуробмен наше всё!<br><br>А если всё-таки не всё, то тут ещё про bitcoin.org подсказывают.<br> https://m.opennet.dev/openforum/vsluhforumID3/75727.html#57 Fri, 25 Mar 2011 18:14:13 GMT Где именно ниже, а то уже много? Ну и написанное на заборе не валидируется по прибитому в браузере. (хотя... смотря как родители воспитали :)<br>