Э, нет, В убийстве человека, провалившегося сквозь настил моста, виновен прогнивший настил. ЗАменить на заведомо исправный.

(Reply to this) (Thread)

ага-ага, и в том что на этом настиле было написано: "новый провереный иди смело" тоже виноват настил.

(Reply to this) (Parent) (Thread)

Ничего такого на настиле не было написано. Все кто следит за новостями в области информационной безопасности уже два года знают, что именно при электронной подписи ПРЕДОСТАВЛЕННОГО ДРУГИМ ЧЕЛОВЕКОМ КОНТЕНТА MD5 НЕЛьЗЯ использовать. Ровно потому что это дает возможность автору контента подменить подписанный документ так, чтобы подпись осталась валидной.

Соответственно, человек, подписывающийся под принесенным другим человеком набором байт с помощью md5+rsa подписывается фактически под произвольным набором байт не глядя. То есть фактически мы выдаем человеку пустой бланк со своей подписью и говорим "впиши что хочешь".

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

(Reply to this) (Parent) (Thread)

у хэшей оказываетца бывают коллизии! кто бы мог подумать!

приминительно к ssl сертификатам (шо написано по ссылке) проблема происходит ровно в том месте где "browser trusts by default" и нигде более (кроме того что вопрос доверия в этом партикулярном месте вообще третьестепенный и порождает абсолютно фальшивую секурность (ибо доверие издателю сертификата не решает нихера в данном случае (кто блять мешает сайту фишеров зарестрировать себе настоящий валидный сертификат???!!!))

(Reply to this) (Parent) (Thread)

Вся идея электронной подписи основана на том, что НАМЕРЕННО получить коллизию можно только за время, сравнимое с временем существования Вселенной. После того, как для MD5 нашли способ получать коллизию за 8 часов, этот хэш стал непригоден для электронной подписи.
кто блять мешает сайту фишеров зарестрировать себе настоящий валидный сертификат???!!!))

Ну вообще-то репутация того, кто эти сертификаты выдает. Деньги VeriSign берет именно за то, что ПРОВЕРЯЕТ, что указанное в сертификате доменное имя действительно принадлежит тому, кто подал заявку на сертификат.

Правда, конечно, если в VeriSign позвонят из Форт-Мида они чего только не выпишут, но это уже отдельный вопрос.

Грубо говоря, зелененький цвет адресной строки означает ровно одно - что кто-то поручился своей электронной подписью за то, что введенное в эту строку доменное имя и лежащий на сервере ключ подписи принадлежат одному и тому же лицу. Причем этот кто-то - из тех, кому доверяет браузер. (а этот список вполне доступен редактированию пользователем)

Поэтому фишинговому сайту вряд ли удастся получить сертификат на www.paypal.com.

(Reply to this) (Parent) (Thread)

> зелененький цвет адресной строки означает ровно одно - что кто-то поручился своей электронной подписью за то, что введенное в эту строку доменное имя и лежащий на сервере ключ подписи принадлежат одному и тому же лицу.

ПРАВИЛЬНО!!!

А кто мешает ЧЕСТНО ВЫПОЛНИТЬ ЭТИ УСЛОВИЯ?

одному лицу зарегистрировать домен vikontakte.ru и самому же написать ПОЛНОСТЬЮ ПРАВДИВУЮ заявку с CN=vikontakte.ru

Я уже разсказывал про Банк Платина, который требует два раза ввести фамилию для подтверждения подлинности владельца....

(Reply to this) (Parent) (Thread)

Ну если ты ре разглядел, что "это vikontakte, а не vkontakte", то ни verisign, ни vkontakte тут не виноваты. Это все равно что подавать иск к ФРС США за то, что в обменнике на углу тебе подсунули фальшивые доллары.

ФРС США сделала все что могла - она встроила в банкноты несколько степеней защиты, она опубликовала критерии, по которым можно отличить подлинный доллар от фальшивых. Если ты сослепу не разглядел - сам виноват.

(Reply to this) (Parent) (Thread)

> Ну если ты ре разглядел, что "это vikontakte, а не vkontakte", то ни verisign, ни vkontakte тут не виноваты.

Опять правильно!!!

ещё чуть-чуть и вы сделаете верный вывод о полезности зелёной адресной строки!

(Reply to this) (Parent)

тоесть проблема (которая к ssl слабоприменима) автоматом снимаеца путём показывания юзеру текста сертификата.
юзер видит кучу левых буков и понимает всю засаду.
всё.

что же касается проблемы неотказуемости, самой сложной (имхо) проблемы для любого вида документооборота (и бумажного в ПЕРВУЮ ОЧЕРЕДЬ)

то надо удлиннять хэш и укорачивать текст. ага ага! укорачивать таки текст.

(Reply to this) (Parent) (Thread)

Нифига не снимается. Проблема как раз в том, что нехороший человек может написать в сертификате ВСЕ, ЧТО УГОДНО, и это все-что угодно, будет заверено валидной электронной подписью УЦ.

Юзер там увидит не кучу левых букв. Он увидит вполне правые буквы

CommonName=www.paypal.com
Organization=PayPal Inc.

В то время как УЦ подписывал сертификат с
CommonName=pupkin.narod.ru
Organization=ПБОЮЛ Вася Пупкин

(Reply to this) (Parent) (Thread)

> Юзер там увидит не кучу левых букв.

а каким же святым духом возникнет воздействие на хэш функцию?
у неё случайно открылся второй аргумент?

(Reply to this) (Parent) (Thread)

Открылся алгоритм получения коллизий. Который позволяет взять два разных текста и подописывать к ним в хвост дополнительные байты, чтобы получилась одинаковая хэш-функция. При этом эти дополнительные байты это не просто так - а вполне валидные открытые ключи RSA.

(Reply to this) (Parent) (Thread)

> подописывать к ним в хвост дополнительные байты

а теперь вернитесь на два комента выше и прочитайте мои слова:
"юзер увидит левые символы"

s/левые/дополнительные/
s/символы/байты/

(Reply to this) (Parent) (Thread)

Надо дочитывать до конца то, что я пишу. (может если до конца дочитывать и на фишинг попадаться не будешь)

В любом сертификате есть 32 или 64 байта нечеловекочитаемых символов. Открытый ключ называются.

Коллизия строится подбором таких двух ключевых пар RSA, что
открытый ключ А вместе с текстом X дает ту же хэш-сумму, что открытый ключ B вместе с текстом У. (ну на самом деле не текстом, а ASN.1 структурой данных сертификата, но это не важно).

Злоумышленник имеет в своем распоряжении закрытые ключи от обоих ключевых пар, поэтому может послать в УЦ заявку с текстом X и открытым ключом A, честно подписав ее закрытым ключом A.

Получив сертификат, он отрезает от него подпись, подцепляет его к паре из текста Y и открытого ключа B и получает сертификат на ключевую пару B. Закрытый ключ B у него есть, так что он вполне может доказать клиенту TLS что он Y.

(Reply to this) (Parent) (Thread)

(A,kA),(B,kB) -- key pairs of a fisher
(C,kC) -- key pair of a CA
X,Y -- some certificate text

sign :: Text->Privkey->Signature
check :: Text->Signature->Pubkey->Boolean

fisher --> CA : ((X,A) , sign (X,A) kA)
fisher <-- CA : ( ((X,A) , sign (X,A) kA) , sign ((X,A) , sign (X,A) kA) kC )

fisher --> User : ( ((Y,B) , sign (Y,B) kB) , sign ((X,A) , sign (X,A) kA) kC )

WHERE 
check ((Y,B) , sign (Y,B) kB) (sign ((X,A) , sign (X,A) kA) kC) C == true

(Reply to this) (Parent)