Комментарии 29
Мда. Плюсую, актуально.
Хотя исходники, имхо, бы лучше на какой-нить опен-сорс хостинг, а не в текст статьи…
Хотя исходники, имхо, бы лучше на какой-нить опен-сорс хостинг, а не в текст статьи…
Как раз на днях думал, а поддерживают ли not-IE браузеры такого рода фишки, в частности рутокен. Для ентерпрайза большой плюс.
В OpenJDK работает?
А почему бы не использовать их же webtoken ( www.rutokenweb.ru/ )?
Речь идет о самом токене Рутокен Web или же о комплексном решении «Рутокен Web + плагины к браузеру»?
Вместе с плагином, потому что сам по сееб Web не сильно отличается от ECP
Основная разница в том, что java-апплет построен на базе OpenSSL c ГОСТом и апплет расширяем, так как даны его исходники. То есть все что есть в OpenSSL можно добавить в апплет. А OpenSSL поддерживает цифровые сертификаты X.509 и списки отзыва CRL, все форматы защищенных (подписанных и зашифрованных) сообщений — PKCS#7, CMS, S/MIME, заявки на сертификаты в форматах PKCS#10/SPARC, функциональность PKI, различные криптографические протоколы и т.п.
Решение Рутокен Web закрытое. Оно имеет четко очерченный функционал, направленный на аутентификацию пользователя. Предлагаемое решение, это я так понимаю, конструктор для разработки собственных решений.
Речь идет о самом токене Рутокен Web или же о комплексном решении «Рутокен Web + плагины к браузеру»?
Предлагаемое решение не выдерживает никакой критики. Оно абсолютно нежизнеспособно.
Во-первых, в яве постоянно находят новые уязвимости. Глядя на историю таких уязвимостей, становится очевидно, что с большой вероятностью в хакерском сообществе имеется информация о неизвестных сейчас уязвимостях и средства их эксплуатации (т.н zeroday exploits). Что вы скажете вашим клиентам, когда их взломают через эту яву и уведут, например деньги с ДБО? Хотя я знаю, вы скажете, что виноват Оракл, а вы тут не при чем. С современным уровнем ответственности разработчиков («this software is provided without warranty of any kind») никто не хочет ни за что отвечать.
Я например отключил плагин ява во всех браузерах. Те, кто его не отключили, не имеют (морального) права предъявлять претензии в случае взлома, так как все прекрасно знают, что это решето, и если человек его не отключает, он сам себе Буратино.
Я надеюсь, что Оракл когда-нибудь либо уберет веб-плагин, либо перестанет его включать при установке Явы, либо добрые ребята из Гугла заблокируют его на уровне браузера, ибо так продолжать нельзя. Флеш мы потихоньку выдавливаем с ПК, теперь пора и яве подвинуться.
Во-вторых, решение уродливое и громоздкое. Какие-то тонны бибиотек (бинарных, только x86, никем не проверенных, нгеизвестно что в себе содержащих) и непонятного кода, написанного какими-то анонимусами. И это предлагается запускать на своем компьютере? это неразумно.
Решение делать и устанавливать какие-то проприетарные плагины, тоже глупо. Для работы средств ЭЦП давно уже пора предусмотреть какие-то возможности в стандарте HTML, и поддержку таких средств должны реализовать производители браузеров. И делать это на основе открытых стандартов. А рутокен — местечковая временная контора, и как только уважаемые компании вроде Гугл или Яндекс примут участие в разработке, уверен, ситуация с массовой криптографией и ЭЦП улучшится. Потому что сегодня в разработке средств ЭЦП принимают участие сомнительные фирмочки, продвигающие плохие, непроверенные, непроверяемые (нет исходников), проприетарные, with vendor lock-in feature средства, место которым на свалке истории. Массовая криптография и ЭЦП станут повсеместными в будущем, и хотелось бы, чтобы у них был надежный проверенный фундамент, а не чтобы какие-то сомнительные компании захватили этот рынок с проприетарными продуктами, как например это удалось сделать когда-то майкрософту, последствия чего мы до сих пор расхлебываем.
> а при загрузке на web-странице будет распаковывать их в папку %TEMP% и уже оттуда использовать
Это жесть. Ява имеет право создавать файлы на клиенте? Неудивительно, что через нее трояны и устанавливаются.
Во-первых, в яве постоянно находят новые уязвимости. Глядя на историю таких уязвимостей, становится очевидно, что с большой вероятностью в хакерском сообществе имеется информация о неизвестных сейчас уязвимостях и средства их эксплуатации (т.н zeroday exploits). Что вы скажете вашим клиентам, когда их взломают через эту яву и уведут, например деньги с ДБО? Хотя я знаю, вы скажете, что виноват Оракл, а вы тут не при чем. С современным уровнем ответственности разработчиков («this software is provided without warranty of any kind») никто не хочет ни за что отвечать.
Я например отключил плагин ява во всех браузерах. Те, кто его не отключили, не имеют (морального) права предъявлять претензии в случае взлома, так как все прекрасно знают, что это решето, и если человек его не отключает, он сам себе Буратино.
Я надеюсь, что Оракл когда-нибудь либо уберет веб-плагин, либо перестанет его включать при установке Явы, либо добрые ребята из Гугла заблокируют его на уровне браузера, ибо так продолжать нельзя. Флеш мы потихоньку выдавливаем с ПК, теперь пора и яве подвинуться.
Во-вторых, решение уродливое и громоздкое. Какие-то тонны бибиотек (бинарных, только x86, никем не проверенных, нгеизвестно что в себе содержащих) и непонятного кода, написанного какими-то анонимусами. И это предлагается запускать на своем компьютере? это неразумно.
Решение делать и устанавливать какие-то проприетарные плагины, тоже глупо. Для работы средств ЭЦП давно уже пора предусмотреть какие-то возможности в стандарте HTML, и поддержку таких средств должны реализовать производители браузеров. И делать это на основе открытых стандартов. А рутокен — местечковая временная контора, и как только уважаемые компании вроде Гугл или Яндекс примут участие в разработке, уверен, ситуация с массовой криптографией и ЭЦП улучшится. Потому что сегодня в разработке средств ЭЦП принимают участие сомнительные фирмочки, продвигающие плохие, непроверенные, непроверяемые (нет исходников), проприетарные, with vendor lock-in feature средства, место которым на свалке истории. Массовая криптография и ЭЦП станут повсеместными в будущем, и хотелось бы, чтобы у них был надежный проверенный фундамент, а не чтобы какие-то сомнительные компании захватили этот рынок с проприетарными продуктами, как например это удалось сделать когда-то майкрософту, последствия чего мы до сих пор расхлебываем.
> а при загрузке на web-странице будет распаковывать их в папку %TEMP% и уже оттуда использовать
Это жесть. Ява имеет право создавать файлы на клиенте? Неудивительно, что через нее трояны и устанавливаются.
>Во-первых, в яве постоянно находят новые уязвимости. Глядя на историю таких уязвимостей, становится >очевидно, что с большой вероятностью в хакерском сообществе имеется информация о неизвестных сейчас >уязвимостях и средства их эксплуатации (т.н zeroday exploits).
Эмоционально и необоснованно. В любых платформах бывают уязвимости и разработчики платформы с ними успешно разбираются. Ява в этом плане абсолютно нормальная платформа, которая достаточно распространена, а, значит, оттестирована. И как раз многие системы ДБО уважаемых банков сделаны на яве.
>Что вы скажете вашим клиентам, когда их >взломают через эту яву и уведут, например деньги с ДБО?
>Хотя я знаю, вы скажете, что виноват Оракл, а вы тут >не при чем. С современным уровнем ответственности >разработчиков («this software is provided without warranty >of any kind») никто не хочет ни за что отвечать.
Вы, как я понял, пишете о вашем личном уровне ответственности?
>Во-вторых, решение уродливое и громоздкое. Какие-то тонны бибиотек (бинарных, только x86, никем не >проверенных, нгеизвестно что в себе содержащих) и непонятного кода, написанного какими-то анонимусами.
>И это предлагается запускать на своем компьютере? это неразумно.
Вы либо поленились разбираться, либо квалификация не позволяет. Эти библиотеки, в основном — OpenSSL. Который доступен в исходниках. OpenSSL используется в таких распространенных продуктах как Apache, OpenVPN, серверах IBM. То есть это реально уважаемая в мире библиотека. А то что x86 — для примера остаточно. Эти все библиотеки есть под x64 и не только по винду. Непонятный код написанный анонимусами открыт — разработчики разберутся в нем и он станет понятным.
Если вам что-то непонятно, то значит вы не целевая аудитория для этой статьи.
>Решение делать и устанавливать какие-то проприетарные плагины, тоже глупо. Для работы средств ЭЦП >давно уже пора предусмотреть какие-то возможности в стандарте HTML, и поддержку таких средств должны >реализовать производители браузеров. И делать это на основе открытых стандартов.
Вы некомпетентны. ЭЦП и делается на основе открытых стандартов. ГОСТы давно уже в RFC, PKCS#7, CMS, S/MIME — в RFC. Мало того, я использую открытую реализацию этих стандартов — OpenSSL.
>А рутокен — >местечковая временная контора, и как только уважаемые компании вроде Гугл или Яндекс >примут участие в >разработке, уверен, ситуация с массовой криптографией и ЭЦП улучшится. Потому что >сегодня в разработке >средств ЭЦП принимают участие сомнительные фирмочки, продвигающие плохие, >непроверенные, >непроверяемые (нет исходников), проприетарные, with vendor lock-in feature средства, >место которым на свалке истории. Массовая криптография и ЭЦП станут повсеместными в будущем, и >хотелось бы, чтобы у них был надежный проверенный фундамент, а не чтобы какие-то сомнительные >компании захватили этот рынок с проприетарными продуктами, как например это удалось сделать когда-то >майкрософту, последствия чего мы до сих пор расхлебываем.
Бла, бла, бла… Эти черные, а те белые. Юношеский максимализм однако. Ах, простите, вам же 20 лет:) Ну почему нет исходников? Я все сделал на open source библиотеке (OpenSSL) и вам отдал все исходники, так вы же их смотреть не хотите.
>Это жесть. Ява имеет право создавать файлы на клиенте? Неудивительно, что через нее трояны и >устанавливаются.
ПОДПИСАННЫЙ java-апплет!
Эмоционально и необоснованно. В любых платформах бывают уязвимости и разработчики платформы с ними успешно разбираются. Ява в этом плане абсолютно нормальная платформа, которая достаточно распространена, а, значит, оттестирована. И как раз многие системы ДБО уважаемых банков сделаны на яве.
>Что вы скажете вашим клиентам, когда их >взломают через эту яву и уведут, например деньги с ДБО?
>Хотя я знаю, вы скажете, что виноват Оракл, а вы тут >не при чем. С современным уровнем ответственности >разработчиков («this software is provided without warranty >of any kind») никто не хочет ни за что отвечать.
Вы, как я понял, пишете о вашем личном уровне ответственности?
>Во-вторых, решение уродливое и громоздкое. Какие-то тонны бибиотек (бинарных, только x86, никем не >проверенных, нгеизвестно что в себе содержащих) и непонятного кода, написанного какими-то анонимусами.
>И это предлагается запускать на своем компьютере? это неразумно.
Вы либо поленились разбираться, либо квалификация не позволяет. Эти библиотеки, в основном — OpenSSL. Который доступен в исходниках. OpenSSL используется в таких распространенных продуктах как Apache, OpenVPN, серверах IBM. То есть это реально уважаемая в мире библиотека. А то что x86 — для примера остаточно. Эти все библиотеки есть под x64 и не только по винду. Непонятный код написанный анонимусами открыт — разработчики разберутся в нем и он станет понятным.
Если вам что-то непонятно, то значит вы не целевая аудитория для этой статьи.
>Решение делать и устанавливать какие-то проприетарные плагины, тоже глупо. Для работы средств ЭЦП >давно уже пора предусмотреть какие-то возможности в стандарте HTML, и поддержку таких средств должны >реализовать производители браузеров. И делать это на основе открытых стандартов.
Вы некомпетентны. ЭЦП и делается на основе открытых стандартов. ГОСТы давно уже в RFC, PKCS#7, CMS, S/MIME — в RFC. Мало того, я использую открытую реализацию этих стандартов — OpenSSL.
>А рутокен — >местечковая временная контора, и как только уважаемые компании вроде Гугл или Яндекс >примут участие в >разработке, уверен, ситуация с массовой криптографией и ЭЦП улучшится. Потому что >сегодня в разработке >средств ЭЦП принимают участие сомнительные фирмочки, продвигающие плохие, >непроверенные, >непроверяемые (нет исходников), проприетарные, with vendor lock-in feature средства, >место которым на свалке истории. Массовая криптография и ЭЦП станут повсеместными в будущем, и >хотелось бы, чтобы у них был надежный проверенный фундамент, а не чтобы какие-то сомнительные >компании захватили этот рынок с проприетарными продуктами, как например это удалось сделать когда-то >майкрософту, последствия чего мы до сих пор расхлебываем.
Бла, бла, бла… Эти черные, а те белые. Юношеский максимализм однако. Ах, простите, вам же 20 лет:) Ну почему нет исходников? Я все сделал на open source библиотеке (OpenSSL) и вам отдал все исходники, так вы же их смотреть не хотите.
>Это жесть. Ява имеет право создавать файлы на клиенте? Неудивительно, что через нее трояны и >устанавливаются.
ПОДПИСАННЫЙ java-апплет!
Что вы скажете вашим клиентам, когда их взломают через эту яву и уведут, например деньги с ДБО?
А что Вы скажете клиентам, если из взломают через винду, через акробат, через МАС ось, через социальную инженерию в конце концов?
Здесь нужен административный подход. ИМХО: явную уязвимость своим продуктом разработчики не создают.
Но если лично Вас что-то не устраивает — предложите автору создать решение под Ваши нужды за определённое вознаграждение. Всем ведь не угодишь. Знаете сколько таких «Нехочух» вроде Вас найдётся. И что: автору за бесплатно всем свои версии переделывать?
Большое спасибо за полноценное решение по использованию OpenSSL + ruToken в апплете!
А есть возможность использовать eToken таким же образом?
По поводу исп. JNI в апплете есть замечания — в случае обновления странички с апплетом
может произайти ошибка «UnsatisfiedLinkError: Native Library *.dll already loaded in another classloader».
Это связано с тем что DLL может быть загружена только один раз. Надо эту ошибку как-то специально обрабатывать.
И я не совсем согласен с тем что нужно DLLки хранить как ресурсы, это увеличивает размер апплета. Апплет будет долго грузиться а этот процесс никак не контролируется, апплет в это время будет недоступен.
А есть возможность использовать eToken таким же образом?
По поводу исп. JNI в апплете есть замечания — в случае обновления странички с апплетом
может произайти ошибка «UnsatisfiedLinkError: Native Library *.dll already loaded in another classloader».
Это связано с тем что DLL может быть загружена только один раз. Надо эту ошибку как-то специально обрабатывать.
И я не совсем согласен с тем что нужно DLLки хранить как ресурсы, это увеличивает размер апплета. Апплет будет долго грузиться а этот процесс никак не контролируется, апплет в это время будет недоступен.
>А есть возможность использовать eToken таким же образом?
Таким же образом (через OpenSSL) — нет, так как eToken с ГОСТом не «прикручен» к OpenSSL.
>По поводу исп. JNI в апплете есть замечания — в случае обновления странички с апплетом
>может произайти ошибка «UnsatisfiedLinkError: Native Library *.dll already loaded in another classloader».
>Это связано с тем что DLL может быть загружена только один раз. Надо эту ошибку как-то специально >обрабатывать.
Спасибо за замечание. При тестировании примера не нарывался.
>И я не совсем согласен с тем что нужно DLLки хранить как ресурсы, это увеличивает размер апплета. >Апплет будет долго грузиться а этот процесс никак не контролируется, апплет в это время будет
недоступен.
Как вариант для DLL-ок можно сделать установщик, который бы не требовал прав сисадмина (на NSYS, например). Он бы их складывал в определенное место, а апплет их бы там искал. Для безопасности инсталлятор так же можно подписывать, используя для проверки подписи на винде механизм верификаци дистрибутивов.
Таким же образом (через OpenSSL) — нет, так как eToken с ГОСТом не «прикручен» к OpenSSL.
>По поводу исп. JNI в апплете есть замечания — в случае обновления странички с апплетом
>может произайти ошибка «UnsatisfiedLinkError: Native Library *.dll already loaded in another classloader».
>Это связано с тем что DLL может быть загружена только один раз. Надо эту ошибку как-то специально >обрабатывать.
Спасибо за замечание. При тестировании примера не нарывался.
>И я не совсем согласен с тем что нужно DLLки хранить как ресурсы, это увеличивает размер апплета. >Апплет будет долго грузиться а этот процесс никак не контролируется, апплет в это время будет
недоступен.
Как вариант для DLL-ок можно сделать установщик, который бы не требовал прав сисадмина (на NSYS, например). Он бы их складывал в определенное место, а апплет их бы там искал. Для безопасности инсталлятор так же можно подписывать, используя для проверки подписи на винде механизм верификаци дистрибутивов.
Ситуация всё равно катастрофическая. Пользователь может только верить, что он подписывает именно то, что видит, ведь апплет-то пришёл с того же источника, который отправляет ему документ на подписание. Предвижу уже, как пользователям подбрасывают документы типа расписок в больших суммах денег, использовав открытый или даже не слишком, WiFi, и атакуя с помощью MitM.
Я бы гораздо больше доверял скриптлету, который обращается за подписанием к локальному веб-сервису, работающему напрямую с токеном. Токен же умеет аппаратно подписывать документы?
И уж поверьте, подобное решение было бы легковеснее (5Мб Lua с библиотеками, к примеру, для веб-сервиса) и переносимее. И что самое главное — более устойчиво к атакам и гораздо более прозрачно для пользователя.
Я бы гораздо больше доверял скриптлету, который обращается за подписанием к локальному веб-сервису, работающему напрямую с токеном. Токен же умеет аппаратно подписывать документы?
И уж поверьте, подобное решение было бы легковеснее (5Мб Lua с библиотеками, к примеру, для веб-сервиса) и переносимее. И что самое главное — более устойчиво к атакам и гораздо более прозрачно для пользователя.
Часть приложений, использующих подпись, не столь требовательны к реальной безопасности :)
Это видео вы мне дали, чтобы я расслабился и подумал о хорошем минутку?
Конечно, Новый Год на носу!
По существу вопроса — Компания Актив разработал и выпустил на рынок решение Рутокен PINPad, я писал о нем тут. Идет активная работа по встраиванию этого решения в российские банки.
По существу вопроса — Компания Актив разработал и выпустил на рынок решение Рутокен PINPad, я писал о нем тут. Идет активная работа по встраиванию этого решения в российские банки.
Да, читал, отличная штука, но к ЭЦП в браузере её не прикрутишь.
Почему же не прикрутишь? Рутокен PINPad «внутри» такой же криптографический токен, как и Рутокен ЭЦП, только с экраном, на котором можно смотреть — что подписывается. У них даже программные интерфейсы практически одинаковые. Тут вот есть пример подписи в браузере с помощью PINPada pinpad.rutoken.ru/demo.php.
Тогда цены такой штуке нет, правда только если то, что подписываешь — удобочитаемо. Мне пока приходилось общаться с таким вот, и человеку там делать нечего, хотя подписывать это просят именно человека, а за отправку с подписью неправильных данных иногда грозит уголовная ответственность.
Хочу добавить некоторые первоисточники к тем проблемам, которые я описал.
Наглядность подписания.
USB токен с JavaScript API (увы, только аутентификация). Поскольку у нас не видно особых альтернатив рутокену, и дополнительный уровень абстракции для использования любых токенов не нужен, можно использовать аналогичную систему драйверов. Либо предложенный мной вариант.
Наглядность подписания.
USB токен с JavaScript API (увы, только аутентификация). Поскольку у нас не видно особых альтернатив рутокену, и дополнительный уровень абстракции для использования любых токенов не нужен, можно использовать аналогичную систему драйверов. Либо предложенный мной вариант.
>Я бы гораздо больше доверял скриптлету, который обращается за подписанием к локальному веб-сервису, >работающему напрямую с токеном.
А в чем разница? Сервис вы ставите? Значит вы уверены в том, что это доверенный софт, что его никто не подменил.
В случае с подписанным апплетом (а неподписанному апплету java просто не разрешит вызывать native библиотеки) ситуация такая же. Перед началом работы апплета java скажет «подписан тем-то», а там уж ваше дело — доверять или не доверять.
>Токен же умеет аппаратно подписывать документы?
С помощью Java-апплета документы как раз подписываются аппаратно.
>И уж поверьте, подобное решение было бы легковеснее (5Мб Lua с библиотеками, к примеру, для >веб-сервиса) и переносимее. И что самое главное — более устойчиво к атакам и гораздо более прозрачно >для пользователя
Все библиотеки внутри апплета весят 1.9Мб, а упакованный JAR-архив — 942 Кб.
Ваше решение не более устойчиво к атакам (почему, я описал выше) и гораздо менее прозрачно для пользователя.
А в чем разница? Сервис вы ставите? Значит вы уверены в том, что это доверенный софт, что его никто не подменил.
В случае с подписанным апплетом (а неподписанному апплету java просто не разрешит вызывать native библиотеки) ситуация такая же. Перед началом работы апплета java скажет «подписан тем-то», а там уж ваше дело — доверять или не доверять.
>Токен же умеет аппаратно подписывать документы?
С помощью Java-апплета документы как раз подписываются аппаратно.
>И уж поверьте, подобное решение было бы легковеснее (5Мб Lua с библиотеками, к примеру, для >веб-сервиса) и переносимее. И что самое главное — более устойчиво к атакам и гораздо более прозрачно >для пользователя
Все библиотеки внутри апплета весят 1.9Мб, а упакованный JAR-архив — 942 Кб.
Ваше решение не более устойчиво к атакам (почему, я описал выше) и гораздо менее прозрачно для пользователя.
Если сервис идёт на CD, или может скачиваться с сайта производителя, и однократно устанавливается, у меня к нему больше доверия, чем к некоему апплету, который поставляется третьей стороной (банком, гос. сайтом и т.п.), который ко всему прочему ещё и качается браузером.
Да, с подписью апплетов это замечательно, но когда тебе нужно провести какой-то платёж, а вылезает назойливое окно, говорящее о том, что не ясно, стоит ли доверять источнику, пользователь в большем количестве случаев предпочтёт ответить «доверять», а возможно, ещё и поставит галочку «всегда доверять этому издателю», что может привести для него к очень печальным последствиям.
Это понятно, что JA нужен только как прокладка между содержимым страницы и USB устройством (а точнее, MS CryptoAPI. Можете для тупых, пожалуста, разжевать, зачем же нужен gost.dll?
Поясните, пожалуйста, в чём меньшая устойчивость к атакам, и атакам какого рода.
Также интересно, чем же меньше прозрачность GM плагина, код которого можно посмотреть прямо из браузера, поставляемых производителем токена, перед байткодовым JA, и библиотекой gost.dll и её ещё более загадочными компаньонами, поставляемыми третьими лицами?
Да, с подписью апплетов это замечательно, но когда тебе нужно провести какой-то платёж, а вылезает назойливое окно, говорящее о том, что не ясно, стоит ли доверять источнику, пользователь в большем количестве случаев предпочтёт ответить «доверять», а возможно, ещё и поставит галочку «всегда доверять этому издателю», что может привести для него к очень печальным последствиям.
Это понятно, что JA нужен только как прокладка между содержимым страницы и USB устройством (а точнее, MS CryptoAPI. Можете для тупых, пожалуста, разжевать, зачем же нужен gost.dll?
Поясните, пожалуйста, в чём меньшая устойчивость к атакам, и атакам какого рода.
Также интересно, чем же меньше прозрачность GM плагина, код которого можно посмотреть прямо из браузера, поставляемых производителем токена, перед байткодовым JA, и библиотекой gost.dll и её ещё более загадочными компаньонами, поставляемыми третьими лицами?
>Если сервис идёт на CD, или может скачиваться с сайта производителя, и однократно устанавливается, у меня >к нему больше доверия, чем к некоему апплету, который поставляется третьей стороной (банком, гос. сайтом >и т.п.), который ко всему прочему ещё и качается браузером.
>Да, с подписью апплетов это замечательно, но когда тебе нужно провести какой-то платёж, а вылезает >назойливое окно, говорящее о том, что не ясно, стоит ли доверять источнику, пользователь в большем >количестве случаев предпочтёт ответить «доверять», а возможно, ещё и поставит галочку «всегда доверять >этому издателю», что может привести для него к очень печальным последствиям.
Кроме подмены апплета возможны и другие атаки, которые приведут к подмене вашего же скриптлета на хакерский. И что, пользователь, который как вы считаете не может правильно ответить на вопрос браузера о подписи апплета, полезет смотреть код скриптлета?
Электронная подпись и была придумана, в частности, чтобы можно было убедиться в целостности файла (апплета) без его полного сравнения с эталоном глазами.
>Это понятно, что JA нужен только как прокладка между содержимым страницы и USB устройством (а >точнее, MS CryptoAPI. Можете для тупых, пожалуста, разжевать, зачем же нужен gost.dll?
MS CryptoAPI здесь вообще не используется. JA обращается к OpenSSL, который в свою очередь через engine pkcs11_gost (плагин к OpenSSL) и libp11 (open source PKCS#11 wrapper) обращается к библиотеке rtPKCS11ECP, которая в свою очередь через CCID-драйвер обращается с помощью APDU команд к Рутокен ЭЦП.
С помощью Gost.dll производится упаковка полученной аппаратно подписи ГОСТ Р 34-10.2001 в формат PKCS#7 в соответствии с криптопрошными rfc.
Я не писал что ваше решение менее устойчиво к атакам. «Не более».
>также интересно, чем же меньше прозрачность GM плагина, код которого можно посмотреть прямо из >браузера, поставляемых производителем токена, перед байткодовым JA, и библиотекой gost.dll и её ещё >более загадочными компаньонами, поставляемыми третьими лицами?
Потому что этот плагин требует установленного локально сервиса, а апплет — нет. На современных ОС для работы апплета даже драйвера Рутокен ЭЦП ставить не требуется, так как CCID-дравер по умолчанию имеется в системе.
А для работы вашего решения машину нужно подготавливать, да еще поди и с правами сисадмина. Соответственноо идет привязка к одной машине, из интернет-кафе уже не поработаешь.
А про «код которого можно посмотреть прямо из браузера» — это мало кому надо.
>Да, с подписью апплетов это замечательно, но когда тебе нужно провести какой-то платёж, а вылезает >назойливое окно, говорящее о том, что не ясно, стоит ли доверять источнику, пользователь в большем >количестве случаев предпочтёт ответить «доверять», а возможно, ещё и поставит галочку «всегда доверять >этому издателю», что может привести для него к очень печальным последствиям.
Кроме подмены апплета возможны и другие атаки, которые приведут к подмене вашего же скриптлета на хакерский. И что, пользователь, который как вы считаете не может правильно ответить на вопрос браузера о подписи апплета, полезет смотреть код скриптлета?
Электронная подпись и была придумана, в частности, чтобы можно было убедиться в целостности файла (апплета) без его полного сравнения с эталоном глазами.
>Это понятно, что JA нужен только как прокладка между содержимым страницы и USB устройством (а >точнее, MS CryptoAPI. Можете для тупых, пожалуста, разжевать, зачем же нужен gost.dll?
MS CryptoAPI здесь вообще не используется. JA обращается к OpenSSL, который в свою очередь через engine pkcs11_gost (плагин к OpenSSL) и libp11 (open source PKCS#11 wrapper) обращается к библиотеке rtPKCS11ECP, которая в свою очередь через CCID-драйвер обращается с помощью APDU команд к Рутокен ЭЦП.
С помощью Gost.dll производится упаковка полученной аппаратно подписи ГОСТ Р 34-10.2001 в формат PKCS#7 в соответствии с криптопрошными rfc.
Я не писал что ваше решение менее устойчиво к атакам. «Не более».
>также интересно, чем же меньше прозрачность GM плагина, код которого можно посмотреть прямо из >браузера, поставляемых производителем токена, перед байткодовым JA, и библиотекой gost.dll и её ещё >более загадочными компаньонами, поставляемыми третьими лицами?
Потому что этот плагин требует установленного локально сервиса, а апплет — нет. На современных ОС для работы апплета даже драйвера Рутокен ЭЦП ставить не требуется, так как CCID-дравер по умолчанию имеется в системе.
А для работы вашего решения машину нужно подготавливать, да еще поди и с правами сисадмина. Соответственноо идет привязка к одной машине, из интернет-кафе уже не поработаешь.
А про «код которого можно посмотреть прямо из браузера» — это мало кому надо.
>Если сервис идёт на CD, или может скачиваться с сайта производителя, и однократно устанавливается, у меня >к нему больше доверия, чем к некоему апплету, который поставляется третьей стороной (банком, гос. сайтом >и т.п.), который ко всему прочему ещё и качается браузером.
>Да, с подписью апплетов это замечательно, но когда тебе нужно провести какой-то платёж, а вылезает >назойливое окно, говорящее о том, что не ясно, стоит ли доверять источнику, пользователь в большем >количестве случаев предпочтёт ответить «доверять», а возможно, ещё и поставит галочку «всегда доверять >этому издателю», что может привести для него к очень печальным последствиям.
Кроме подмены апплета возможны и другие атаки, которые приведут к подмене вашего же скриптлета на хакерский. И что, пользователь, который как вы считаете не может правильно ответить на вопрос браузера о подписи апплета, полезет смотреть код скриптлета?
Электронная подпись и была придумана, в частности, чтобы можно было убедиться в целостности файла (апплета) без его полного сравнения с эталоном глазами.
>Это понятно, что JA нужен только как прокладка между содержимым страницы и USB устройством (а >точнее, MS CryptoAPI. Можете для тупых, пожалуста, разжевать, зачем же нужен gost.dll?
MS CryptoAPI здесь вообще не используется. JA обращается к OpenSSL, который в свою очередь через engine pkcs11_gost (плагин к OpenSSL) и libp11 (open source PKCS#11 wrapper) обращается к библиотеке rtPKCS11ECP, которая в свою очередь через CCID-драйвер обращается с помощью APDU команд к Рутокен ЭЦП.
С помощью Gost.dll производится упаковка полученной аппаратно подписи ГОСТ Р 34-10.2001 в формат PKCS#7 в соответствии с криптопрошными rfc.
Я не писал что ваше решение менее устойчиво к атакам. «Не более».
>также интересно, чем же меньше прозрачность GM плагина, код которого можно посмотреть прямо из >браузера, поставляемых производителем токена, перед байткодовым JA, и библиотекой gost.dll и её ещё >более загадочными компаньонами, поставляемыми третьими лицами?
Потому что этот плагин требует установленного локально сервиса, а апплет — нет. На современных ОС для работы апплета даже драйвера Рутокен ЭЦП ставить не требуется, так как CCID-дравер по умолчанию имеется в системе.
А для работы вашего решения машину нужно подготавливать, да еще поди и с правами сисадмина. Соответственноо идет привязка к одной машине, из интернет-кафе уже не поработаешь.
А про «код которого можно посмотреть прямо из браузера» — это мало кому надо.
>Да, с подписью апплетов это замечательно, но когда тебе нужно провести какой-то платёж, а вылезает >назойливое окно, говорящее о том, что не ясно, стоит ли доверять источнику, пользователь в большем >количестве случаев предпочтёт ответить «доверять», а возможно, ещё и поставит галочку «всегда доверять >этому издателю», что может привести для него к очень печальным последствиям.
Кроме подмены апплета возможны и другие атаки, которые приведут к подмене вашего же скриптлета на хакерский. И что, пользователь, который как вы считаете не может правильно ответить на вопрос браузера о подписи апплета, полезет смотреть код скриптлета?
Электронная подпись и была придумана, в частности, чтобы можно было убедиться в целостности файла (апплета) без его полного сравнения с эталоном глазами.
>Это понятно, что JA нужен только как прокладка между содержимым страницы и USB устройством (а >точнее, MS CryptoAPI. Можете для тупых, пожалуста, разжевать, зачем же нужен gost.dll?
MS CryptoAPI здесь вообще не используется. JA обращается к OpenSSL, который в свою очередь через engine pkcs11_gost (плагин к OpenSSL) и libp11 (open source PKCS#11 wrapper) обращается к библиотеке rtPKCS11ECP, которая в свою очередь через CCID-драйвер обращается с помощью APDU команд к Рутокен ЭЦП.
С помощью Gost.dll производится упаковка полученной аппаратно подписи ГОСТ Р 34-10.2001 в формат PKCS#7 в соответствии с криптопрошными rfc.
Я не писал что ваше решение менее устойчиво к атакам. «Не более».
>также интересно, чем же меньше прозрачность GM плагина, код которого можно посмотреть прямо из >браузера, поставляемых производителем токена, перед байткодовым JA, и библиотекой gost.dll и её ещё >более загадочными компаньонами, поставляемыми третьими лицами?
Потому что этот плагин требует установленного локально сервиса, а апплет — нет. На современных ОС для работы апплета даже драйвера Рутокен ЭЦП ставить не требуется, так как CCID-дравер по умолчанию имеется в системе.
А для работы вашего решения машину нужно подготавливать, да еще поди и с правами сисадмина. Соответственноо идет привязка к одной машине, из интернет-кафе уже не поработаешь.
А про «код которого можно посмотреть прямо из браузера» — это мало кому надо.
«У меня есть мечта…»
В самом деле — у меня есть мечта, что когда-нибудь в будущем я смогу обойтись без связки «windows + IE» для клиент-банков и прочего софта, который использует крипто-про. СБИС++, например.
Блин, я надеюсь, что это когда-нибудь будет.
В самом деле — у меня есть мечта, что когда-нибудь в будущем я смогу обойтись без связки «windows + IE» для клиент-банков и прочего софта, который использует крипто-про. СБИС++, например.
Блин, я надеюсь, что это когда-нибудь будет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Электронная подпись в браузере с помощью OpenSSL и СКЗИ Рутокен ЭЦП