Консорциум W3C анонсировал (http://www.w3.org/News/2012#entry-9564) первый черновой вариант web-стандарта Web Cryptography API (http://www.w3.org/TR/2012/WD-WebCryptoAPI-20120913/), определяющего JavaScript API для выполнения базовых криптографических операций на стороне web-приложений, таких как манипуляции с криптографическими хэшами, генерация и проверка цифровых подписей, кодирование и декодирования данных с использованием различных методов шифрования, формирование криптографически надёжных случайных чисел.
В API также предусмотрены функции для генерации ключей и управления ими. Для размещения ключей предусмотрено как временное хранилище, действующее только в пределах текущего сеанса, так и постоянное хранилище. Доступ к ключам осуществляется на основе привязки к домену (same-origin (http://ru.wikipedia.org/wiki/%D0%9F%D1%8...В качестве примеров применения Web Cryptography API называется обеспечение аутентификации, использование цифровых подписей, сохранение целостности данных, реализация шифрованных коммуникаций, отличных от SSL/TLS.
URL: http://www.w3.org/News/2012#entry-9564
Новость: https://www.opennet.ru/opennews/art.shtml?num=34862
Когда же кто-нить заменит этот JavaScript на что-нить поприличнее?
Например, http://www.dartlang.org/
Тоже вариант, но, честно говоря, хотелось бы просто байткод + стандартизация NaCl и эффективный доступ к нему из байткода (была бы пара примерно как Dalvik/NDK). Пиши на чем хочешь, если надо - дергай вычисления нативные вычисления, а если есть желание - хоть интерпретатор Питона туда засунь.
> Тоже вариант, но, честно говоря, хотелось бы просто байткод + стандартизация NaCl
> и эффективный доступ к нему из байткода (была бы пара примерно
> как Dalvik/NDK). Пиши на чем хочешь, если надо - дергай вычисления
> нативные вычисления, а если есть желание - хоть интерпретатор Питона туда
> засунь.есть же JVM и Java-аплеты - чем не устраивает ? хотя компиляция байткода в натив не очень очевидна
> есть же JVM и Java-аплеты — чем не устраивает ?как минимум — политикой распространения и тем, что это левая по отношению к браузеру фиготень.
>> есть же JVM и Java-аплеты — чем не устраивает ?
> как минимум — политикой распространения и тем, что это левая по отношению
> к браузеру фиготень.ну я бы сказал что движок жаваскрипта такая же левая хрень по отношению к браузеру
а жавамашины щас на любой вкус, OpenJDK вообще гпл-православная и является стандартной реализацией JVM начиная с 7 версии
> ну я бы сказал что движок жаваскрипта такая же левая хрень по
> отношению к браузерулучше не говори: можешь оконфузиться.
> а жавамашины щас на любой вкус, OpenJDK вообще гпл-православная и является стандартной
> реализацией JVM начиная с 7 версиии что? удачи тебе в написании кода для «чистой» JVM.
> ну я бы сказал что движок жаваскрипта такая же левая хрень по
> отношению к браузеруНе совсем так: скрипт может содержаться прямо в HTMLке. Как кусок текста. А с явой так не катит. Не говоря о том что пока ее рантайм взлетит - можно кофе попить успеть.
Не устраивает:
1) привязкой к Ораклу, который в последнее время(и не только) совсем невменяем
2) тормозностью и прожорливостью джавы и невозможностью от этого избавиться
3) тем, что далеко не всё хорошо ложится на jvm
> Руки надо затачивать у программеровТак идите и заточите. Всей планете, которая клепает сайтики и сайты. Как закончите - приходите.
>Тоже вариант, но, честно говоря, хотелось бы просто байткод + стандартизация NaCl и эффективный доступ к нему из байткода (была бы пара примерно как Dalvik/NDK). Пиши на чем хочешь, если надо - дергай вычисления нативные вычисления, а если есть желание - хоть интерпретатор Питона туда засунь.Джава с NaCl, одно дебаг эвривэр решето, второе вообще непортабельное, а про его безопасность даже подумать страшно(или смешно). Эта дрянь уже была в моём уютном Вэбе и была вышвырнута поганой метлой. Ходить по тем же граблям еще раз? Спасибо не надо.
Может объясните, какимбоком вообще может быть уязвим NaCl? Или так, болезненные фантазии? А что до портабельности - вариант с LLVM у них допилен, если вы не в курсе. И да,там специальный LLVM, байткод которого портабелен.
>Может объясните, какимбоком вообще может быть уязвим NaCl?Так же как ActiveX
>И да,там специальный LLVM, байткод которого портабелен.
Байткод и натив ― взаимоисключающие параграфы.
Э... Вы вообще с идеей NaCl знакомы, или от балды пишете? Там тупо ограничивается alignment инструкций так, что в принципе исполнение данных невозможно - нет способа сделать соотвествующий переход, плюс ограничивается набор приемлемых инструкций. Всё это верифицируется движком NaCl в браузере.По байткоду и нативу - поинтересуйтесь, как работают компиляторы - хоть llvm, хоть gсс - работа идёт со своим представлением, которое может быть сериализовано - получите байткод. Генерация кода для платформы - практичсеки последний шаг. Вот этот шаг в случае NaCl и делается на клиенте - получаете чистейший натив.
Вообще похоже, что вы совершенно не в курсе о чем речь.
> Э... Вы вообще с идеей NaCl знакомы, или от балды пишете? Там
> тупо ограничивается alignment инструкций так, что в принципе исполнение данных невозможноДостаточно знаком не столько с NaCl, сколько lowlevel кодингом, чтобы не писать, что "alignment инструкций" исключает выполнение данных =)
Загрузить из инета блоб с машинными инструкциями, прогнать через фильтры и запустить в контексте системного процесса. Бу. Га. Га.
Уверен, что в самом гугле немногие верят, что подобная практика когда-либо будет распространена в Вэбе.> Вот этот шаг в случае NaCl и делается на клиенте
> - получаете чистейший натив.Подумаешь, небольшой такой шаг, скомпилировать, да?
Нет. То что нужно компилировать, то по определению не натив.> Вообще похоже, что вы совершенно не в курсе о чем речь.
Речь о копипасте из пиаристический статей? Я угадал?
А кроме бугага что-то предъявить можете? И гугловское описание читали, конечно? Кстати, в Хроме NaCl уже версий несколько как активне по умолчанию - что-то про взломы не слышно. Не удивляет это вас?Плевать, как называть преобразование llvm-байткода в исполняемую форму - важно что получаем нормальный шустрый код, который ничем не интерпретируется, туда не лезет сбор статистики JIT и тому подобное, и что куча обычного сишного кода в эту форму компилируется без малейших проблем.
И нет, речь идет о технической статейке с описанием работы NaCl - там разжевано всё - дальше некуда. Но вы её либо не читали либо тупо игнорируете.
> в Хроме NaCl уже версий несколько как активне по умолчанию —
> что-то про взломы не слышно. Не удивляет это вас?а чего тут удивительного, что Джо — Неуловимый?
>Плевать, как называть преобразование llvm-байткода в исполняемую форму - важно что получаем нормальный шустрый код, который ничем не интерпретируется, туда не лезет сбор статистики JIT и тому подобное, и что куча обычного сишного кода в эту форму компилируется без малейших проблем.Тут такая ситуация:
Чем ближе код к машинному, тем больше вопросов по совместимости с железками, операционками и браузерами и по безопасности, очевидно. Дыбаг эвривэр одним словом.
В Вэбе такой номер не проходит. С DOM-ом и системными вызовами он будет ровно с такой же скоростью работать или еще медленнее, чем интерпретатор браузера, а проблем всем создает на порядки больше, чем любой скриптовый язык. В браузере нужен именно интерпретатор, общедоступный, стандартизированный и проверенный.>И нет, речь идет о технической статейке с описанием работы NaCl - там разжевано всё - дальше некуда. Но вы её либо не читали либо тупо игнорируете.
хз, к чему вы апеллируете, но в этом NaCl нет ничего нового. Они предсказуемо рассчитывают, на сегментацию, DEP, фильтры инструкций и т.п. Забавно, что всё это добро тоже железо- и OS-зависимое.
> Всё это верифицируется движком NaCl в браузере.то же самое говорили и про жабу. скажи, пожалуйста: раз в жабе мало того, что машинного кода нет, так ещё и верификация во все поля — откуда там постоянно уязвимости берутся?
Да прочти спеку, она довольно занятна. Если коротко - угрозы a-la js (кривая обработка вызовов, доступных из песочницы) никуда не деваются. Но набор инструкций и их расположение ограничены. Чтобы подобное где-то ещё применялось я не читал.
> Да прочти спеку, она довольно занятна.да при чём тут спеки-то? никакой верификатор не является на 100% надёжным. как и рантайм. ну, нагенерю я такое, что верификатор просто не сможет верно отследить, куда в конце концов попадает mov — это не так уж и сложно (хотя и не так просто). и всё, приехали.
> Э... Вы вообще с идеей NaCl знакомы, или от балды пишете? Там
> тупо ограничивается alignment инструкций так, что в принципе исполнение данных невозможноПохоже, вы не знакомы с устройством процессоров и тем как выполняется код. Или проще говоря, вы являетесь АБСОЛЮТНЫМ ЛАМЕРОМ в этом вопросе, если вам так понятнее.
> Всё это верифицируется движком NaCl в браузере.Он на activex похож прежде всего тем что он есть только в одном расово верном браузере, для начала. Гугл уже достал своими вебапликухами которые не работают нигде кроме хрома. Тоже мне, замена микрософта подоспела. Более наглая и шустрая.
> а если есть желание - хоть интерпретатор Питона туда засунь.Ну так напиши интерпритатор питона на JS. Извращаться - так уж по полной!
Разницу в скорости выполнения такого изврата и практически обычного cpython не понимаете, да?
> Разницу в скорости выполнения такого изврата и практически обычного cpython не понимаете, да?На фоне питоня JS очень быстрый язык, так что разницу никто и не заметит :)
Ну да. Вместо того чтобы дать достаточно быструю числодробилку (на базе NaCl, к примеру) они на каждый чих будут клепать специфические интерфейсы? "Гениальная" идея - прибить софт к алгоритмике, доступной в браузере.
Чтобы потом каждый пыонер тащил в систему свою криптографию с блекджеком и шлюхами? Спасибо не надо.
Угу, лучше чтобы браузер определял, какие алгоритмы возможны. Как же.
1) По твоему лучше если злоумышленник, подменив удаленный сервер, заменит код NaCl на свой зонд со всеми вытекающими?2) Пионерские XOR в качестве криптографии не нужны.
3) Драфт описывает интерфейсы, а не реализацию браузеров. Браузер вполне может не реализовывать криптоалгоритмы самостоятельно, а перенаправлять запросы javascript специализированному криптопровайдеру, который может выполняться даже в отдельном процессе.
1) Злоумышленник с тем же успехом может и клиентские вызовы к API на что угодно заменить2) кто всерьёз к безопасности относится - у того будут нормальные алгоритмы. А кто абы как - у того и без XOR будет дыра на дыре. А вот что будут какие-нибудь эллиптические кривые или понимание формата ключей OpenSSH вбито в браузеры - сильно сомневаюсь. Скорее всего ограничатся стандартным набором - AES/RSA.
3) Драфт прибивает к браузеру конкретную область сложных вычислений вместо того чтобы дать общий механизм для них. Если б они только абстрактное защищенное хранилище определили, где браузер бы сам пароли у пользователя спрашивал и т.п. - были бы молодцы. А они тупо ограничивают доступную алгоритмику.
1) Подменив эти API приватного ключа то он все равно не получит.2 и 3) Вы вообще документ читали нет? "As the API is meant to be extensible in order to keep up with future developments within cryptography and to provide flexibility, there are no strictly required algorithms. Thus users of this API should check to see what algorithms are currently recommended and supported by implementations."
А какой смысл прятать свой приватный ключ от кода, сгруженного с сервера, на котором и живут твои данные?И то что оно meant - это одно. А потом окажется, что какой-нибудь IE не реализует эллиптические кривые - и всё, кури бамбук.
> 1) Злоумышленник с тем же успехом может и клиентские вызовы к API
> на что угодно заменитьСильно сложнее - для этого юзеру надо всю ОС расхакать вдоль и поперек.
Интересно, чем не устроил стандартный браузерный функционал SSL/TLS ключей?
Ты в курсе вообще что такое криптография, мальчик?
> Ты в курсе вообще что такое криптография, мальчик?Да, вот я в курсе и поэтому не особо понимаю: а что помешает атакующему заменять скрипты? Проблема в том что код грузится ремотно. Всегда. А значит атакующий обладает приличными шансами его подменить. Ну и толку с такой криптографии?
У например gpg или иных подобных есть коронное преимущество: бинарь скачан заранее. А то что атакующему вот прям ща приспичило атаковать - совсем не обязывает меня пойти и сгрузить именно его затрояненый бинарник, вот прям ща и без какой либо аутентификации производителя бинарника. А вот JS - он как раз об этом самом: кто угодно может вгружать какие угодно скрипты. А вот этим скрипты совсем не обязаны оперировать криптографией именно так как я ожидаю. Например, скрипт шифрования сообщений может при отправке просто отправить до кучи не шифрованную или шифрованную ключом атакующего копию налево. И поди там еще разберись что тебя надурили...
Лучше бы доступ к локальным процессам стандартизовали, сколько можно, актывыксы всякие, флеши, локальные сервера, достало.
> Лучше бы доступ к локальным процессам стандартизовали, сколько можно, актывыксы всякие,
> флеши, локальные сервера, достало.Дык HTML5. И да, доступ к локальным процессам - упаси боже! Как самый максимум - локальные индексированные/скульные бд и доступ к файлам которые юзер выбрал. И то сцыкотно. А то получится очередное сито типа Java, где каждый месяц затыкают дыры вида "атакующий может вылезти за пределы песочницы".
Да просто надо выставить стандартный API - к примеру D-BUS интерфейс тот же (на отдельной шине, доступной для недоверенных процессов). На винде хз - но тоже что-то аналогичное должно быть, по идее. И пусть веб-приложение пуляет и слушает события, если в системе есть что-то, что умеет с этим взаимодействовать - флаг в руки. Это явно будет прямее, чем, к примеру, нынешняя хромовская сообщалка о письмах в gmail.
> Да просто надо выставить стандартный API - к примеру D-BUS интерфейс...Вооот, нормальный вариант.
> Дык HTML5. И да, доступ к локальным процессам - упаси боже!
Дык не может он. Упаси боже напрямую, а если нормальный интерфейс сделать то вполне нормально, ничего особо страшного, и так куча апи есть в каждом из которых может быть дыра, зато полезно, у меня вот сейчас железка (usb считыватель) особый лежит, надо к нему доступ делать, а как? единственное что приходит на ум это писать http сервер который будет ставится на локальный комп, работать с ним и отвечать по http, но блин изврат же, через сетевой все гонять, порты открывать, на файеры нарываться..
> вот сейчас железка (usb считыватель) особый лежит, надо к нему доступ
> делать, а как?А потом начнется - "кто угодно может сделать что угодно, ремотно".
О ремотно речи нет, "драйвер", точнее ПО которое будет работать с железкой и отдавать нужное в браузер, надо ставить точно так же как и остальное, разрешения на копирование, установку, запуск, админские права и т.п, более того можно предусмотреть предупреждения в самом браузере, тогда будет даже лучше чем сейчас т.к. сейчас насколько я понимаю с локальным сервером можно общаться без каких либо предупреждений, вопрос не в том что это нельзя сделать сейчас, делается без хаков, но через ж, вопрос в единообразии, удобстве и дополнительном контроле) так почему бы и нет?
> в единообразии, удобстве и дополнительном контроле) так почему бы и нет?Потому что мы уже видим к чему это привело в Java. А два раза на одни и те же грабли может наступить только бледнолицый брат :)
Да ну, сравнили мне тоже с жабой)
> вот сейчас железка (usb считыватель) особый лежит, надо к нему доступ
> делать, а как?доблестные китайские комсомольцы. сначала изобретают себе препятствия, а потом героически их преодолевают.
Так это и есть одна из заменяющий явааплеты технологий. Хотя пусть и разграниченный, но доступ к приватным ключам НАПРЯМУЮ из БРАУЗЕРА... - страшно!
Думаете вводить пароль в форму и гонять его плэйнтекстом конечно безопаснее?
Никогда не пользовались SSL сертификатом в браузере?
Он о том, что любой джиттер можно шваркнуть, получив доступ к области памяти, где лежат ключи.
> Он о том, что любой джиттер можно шваркнуть, получив доступ к области
> памяти, где лежат ключи.С таким же успехом как сейчас получить доступ к сертификатам, кэшу или сохраненным паролям, напр.:
любой джиттер можно шваркнуть и читать вводимые пароли.
любой джиттер можно шваркнуть, получив доступ к области памяти, где лежат персональные сертификаты.
> Он о том, что любой джиттер можно шваркнуть, получив доступ к области
> памяти, где лежат ключи.Скорее, я бы пекся о том что нет никаких методов отличать скрипты друг от друга и поэтому если некий скрипт якобы "шифрует пароли в форме" - без глубокого анализа человеком фиг поймешь: натурально ли он это делает или же это Вася Пупкин отгрузил свой скрипт и пароль сейчас полетит на его сервер коллекционирования аккаунтов :)
> Думаете вводить пароль в форму и гонять его плэйнтекстом конечно безопаснее?Однофигственно. В данном случае ничто не помешает хаксору вгрузить свой вариант скрипта. Который например шлет его на другой сервер с другим ключом шифрования. Просто потому что браузер грузит все что попросили и никакой защиты от подмены - нет. Поэтому то что скрипт отгрузил Вася Пупкин а вовсе не вон тот сайт - никак и не узнаешь особо. Ну а дальше вся криптография идет лесом. Потому что Пупкин может в свой скрипт прописать что угодно.
>> Думаете вводить пароль в форму и гонять его плэйнтекстом конечно безопаснее?
> Однофигственно. В данном случае ничто не помешает хаксору вгрузить свой вариант скрипта.
> Который например шлет его на другой сервер с другим ключом шифрования.
> Просто потому что браузер грузит все что попросили и никакой защиты
> от подмены - нет. Поэтому то что скрипт отгрузил Вася Пупкин
> а вовсе не вон тот сайт - никак и не узнаешь
> особо. Ну а дальше вся криптография идет лесом. Потому что Пупкин
> может в свой скрипт прописать что угодно.Шлёт на другой сервер и чЁ?
Если не смотреть на сертификат того сайта, который запросил аутентификацию, или не обращать внимания на предупреждения, что часть трафика не шифруется, то...
всё равно далеко не однофигственно. Закрытый ключ Вася не увидит и трафик между юзером и сервером тоже.
> Шлёт на другой сервер и чЁ?Ну, утек пароль. Миссия не выполнена.
> Если не смотреть на сертификат того сайта, который запросил аутентификацию,
Во первых, да, никто на сертификаты каждый раз не смотрит. А я нанимался наизусть заучивать параметры сертификатов всех сайтов?
Во вторых, в случае с сертификатами SSL кто угодно может подписать что угодно, достаточно одному сломаться - и в обломе оказываются вообще ВСЕ. В общем SSL и сертификаты в том виде каком оно сейчас проблему не решают. Доказано comodohacker'ом.
В третьих, грузить код можно и с посторонних сайтов и еще много откуда через всякие инъекции и прочая. Атакующий может скроить вполне легитимно выглядящий запрос к некоему сайту не вызывающий вопросов у браузера, валидный со всех точек зрения. А что ему помешает то? Браузеру пофиг - слать запрос на сайт банка или на сайт Пупкин и Ко.
> или не обращать внимания на предупреждения, что часть трафика не шифруется, то...
Допустим шифруется. А хоть и другим сертом. И? Браузер вякать не будет, если серт валидный. А вот то что это может быть какой-то иной сайт и серт - кто ж там с лупой будет высматривать то это? Да и при юзеже SSL траффик уже зашифрован. Смысл то шифровать еше раз?
> всё равно далеко не однофигственно. Закрытый ключ Вася не увидит и трафик
> между юзером и сервером тоже.Ну да, ну да, все стремные моменты отрабатывает SSL (который в этом плане похож на щит из картона и деревянную саблю). А зачем эта дребедень на JS нужна если ее надежность == надежности SSL?
>Ну, утек пароль. Миссия не выполнена.Пароль, какой пароль? Не, не слышал. У нас секретный ключ.
>В третьих, грузить код можно и с посторонних сайтов и еще много откуда через всякие инъекции и прочая. Атакующий может скроить вполне легитимно выглядящий запрос к некоему сайту не вызывающий вопросов у браузера, валидный со всех точек зрения. А что ему помешает то? Браузеру пофиг - слать запрос на сайт банка или на сайт Пупкин и Ко.
1. Перед использованием персонального сертификата, проверяется сертификат того, кто его запросил и выводит соответствующий запрос с информацией о регистраторе и регистранте.
2. (Что более важно) Ну пошлет браузер запрос на сайт Пупкина. Пупкин узнает сколько и куда юзер денег хотел перевести. Не приятно конечно, но что дальше? Напоминаю авторизация транзакций у нас не по паролю и не по кукам, а по открытому ключу.>Допустим шифруется. А хоть и другим сертом. И? Браузер вякать не будет, если серт валидный.
см. п.1
>Ну да, ну да, все стремные моменты отрабатывает SSL (который в этом плане похож на щит из картона и деревянную саблю). А зачем эта дребедень на JS нужна если ее надежность == надежности SSL?
Если это будет в JS, то надежность == надежности gpg. Никто не заставляет использовать инфраструктуру SSL/TLS. Ну и про картонный щит не надо утрировать тоже.
> Пароль, какой пароль? Не, не слышал. У нас секретный ключ.Ну и славненько, правда вот никто не гарантирует что им пользуется именно правильный скрипт. А чужой скрипт может реализовывать какую угодно нецелевую логику. Если я юзая gpg или почтарь локально еще могу быть более-менее уверен что он не поюзает ключ нецелевым образом и прочая, то скрипт всегда грузится снаружи. И хотя визуально он может быть похож на легитимный нет никаких гарантий что будет сделано именно то что заявлено. Например, он может выступить MITM-ом, гоняя данные кому-то левому. Ключ? Окей, он проавторизует МОИМ ключом какого-то левого ПУПКИНА. Далее Пупкин сможет куролесить от моего лица без каких либо препятствий. А пи...ли прилетят мне. Потому что ключ - мой. А я чем виноват? Не могу же я читать все скрипты которые грузит браузер? Он их тоннами на каждый пук грузит на каждом сайте. Так что этот код априори недоверяем "сам по себе".
>> помешает то? Браузеру пофиг - слать запрос на сайт банка или на сайт Пупкин и Ко.
> 1. Перед использованием персонального сертификата, проверяется сертификат того, кто его
> запросил и выводит соответствующий запрос с информацией о регистраторе и регистранте.Кто выводит? Куда выводит? Посмотреть инфо о сертификате конечно можно, но кто ж это инфо запоминать будет? Ну я б еще понял если б предложили расширение для SSL когда запоминается начальный сертификат и потом если он поменялся - предупреждение. Но ведь как обычно - всем пофигу.
> 2. (Что более важно) Ну пошлет браузер запрос на сайт Пупкина. Пупкин
> узнает сколько и куда юзер денег хотел перевести. Не приятно конечно,
> но что дальше? Напоминаю авторизация транзакций у нас не по паролю
> и не по кукам, а по открытому ключу.А еще пупкиновый скрипт сможет проавторизоваться моим ключом и немного поправить параметры транзакции в процессе. Ну а что ему помешает то? Например, не 100 рублей и Васе, а 10 000 и Пете. В случае хоть того же SSL и браузера такому развитию событий мешает хотя-бы то что я не переустанавливаю браузер по свистку хаксора и к тому же браузер должен поставляться в пакете. Пакет должен быть с валидной цифровой подписью майнтайнеров дистра. Это сильно затрудняет подпихивание мне левого кода использующего криптографию в произвольный момент времени по желанию хаксора. Но в вебе скрипты грузят на каждый пук. Это нормально. Это незаметно. Веб просто так работает. Откуда вытекает что вгрузиться может что попало и без особого одобрения. И без проверки кто вообще писал этот код и по какому поводу он грузится. По поводу довольно странно пытаться доверять этому НЕДОВЕРЯЕМОМУ коду шариться в моих ключах, например. А какие гарантии что это не хаксоровский код и что он ключ поюзает с благими намерениями вообще? А не для того чтобы миллион на свой счет перекинуть или хотя-бы спамануть от моего лица?
>>Допустим шифруется. А хоть и другим сертом. И? Браузер вякать не будет, если серт валидный.
> см. п.1Смотрю. Но так и не понимаю: мне предлагается самому запоминать параметры сертов? Кроме того, надежность такой схемы ограничена сугубо SSL и вся возня с JS - достаточно декоративная.
> надежности SSL?
> Если это будет в JS, то надежность == надежности gpg.Агащаз. Я GPG не перекачиваю по сто раз на дню по свистку хаксора. А вот JS очень даже могу. В этом у JS и даже у "JS дергающего GPG" есть лютейший недостаток. Он всегда может сделать не то что задекларированно. Измениться код может в любой момент. Надежной механики как-то это ограничить или проконтролировать понятным для юзера методом - тупо нет. Поэтому если мой ключ юзанет некий Пупкин по каким-то левым нуждам - я это никак особо не отловлю в большинстве случаев. И надеяться на такую "криптографию" как-то неохота.
> Никто не заставляет использовать инфраструктуру SSL/TLS.
Так если ее не использовать - нет вообще совсем никакой защиты от вгрузки кем попало совершенно левого JS кода под видом легитимного. SSL/TLS пытаются хотя-бы имитировать бурную деятельность. В том виде как оно сделано сейчас - не очень успешно, ибо комодохакер уже показал чему равна надежность всего этого. Но если им не пользоваться - ну вгрузил мне хаксор скрипт.
> Ну и про картонный щит не надо утрировать тоже.
Грубо говоря: ComodoHacker's JS: мамой клянусь, я все честно зашифровал! Я - скрипт вон того банка! И параметры транзакции - верные! А поди заметь что это не настоящий банк скрипт отгрузил, ага. Если на пакет с gpg майнтайнеры цифровую подпись лепят и я могу проверить что gpg отгружен ими а не кем-то еще, то вот JS может вгружаться кем попало и претендовать на то что он - нечто иное.
Все не читал, но в целом претензию понял. Эдакое подобие CSRF, только с полным контролем трафика между клиентом и сервером (либо DNS, используемого юзером) и элементами социнженерии(потому что ну не будет адекватный браузер дёргать ключ из хранилища скриптом, без явной манипуляции юзера, это же очевидно, а юзеры даже больные на голову не включают автологины на банковских сайтах), да не исключено, хотя и затруднительно реально провернуть из-за same origin policy =)
Но опять же, как было сказано, даже в таком грустном случае хаксор не прослушивает трафик и не получает ключ. И это уже не киддис Вася, кстати, а агент Малдер какой-то. И никакого>Однофигственно. В данном случае ничто не помешает хаксору вгрузить свой вариант скрипта.
нет. Много чего помешает.
По поводу невозможности или отсутствию практики проверки скриптов. Это как раз одна из проблем, которую может и должен решить крипто-API.
Не нашел, где там доступ к приватным ключам напрямую из браузера, ткните пальцем пжалуйста.Interface Key не содержит атрибутов содержащую секретную последовательность байтов ключа, только общее описание ключа.
Атрибут extractable интерфейса Key указывает возможно ли делать export ключа или нет.
Холиварщики!!!!!! - читайте основы криптографии открытого ключа, и драфт по крипто API, и не фиг тут разводить холивар про скрипты