|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Vinokurov Andrey 2:5020/400 11 Jan 2002 17:34:20
To : Serge Shikov
Subject : Re: ? is OK if CGI == EXE
--------------------------------------------------------------------------------
Привет.
"Serge Shikov" <shikov@rinet.ru> wrote in message
news:3C3AB43D.C65277CB@rinet.ru...
> > Я говорю ровно то, что _существуют_ задачи, на которых перл уступает
> > по быстродействию экзешнику в сотни раз. И при этом перловый код
> > разрабатывается не быстрее, чем аналогичный плюсовый/сишный.
> А я разве с таким спорил?
Спорил. И даже пример попросил привести.
>Hаверное да, такие задачи есть.
Именно это я и хотел от тебя услышать. Тебе только осталось сказать, что это
и есть те самые задачи, CGI-модули для решения которых разумнее делать на
компилируемых языках, и я буду вполне удовлетворен результатами дискуссии.
> их показать, потому что в моей практике они в вебе не встречаются.
Hу ты сам любишь повторять - если тебе не встречаются, это не значит, что их
нет.
> > И теперь ответь мне на такой вопрос - предположим ты делаешь систему для
> > решения задач через инет с предварительной авторизацией (через проверку
> > подписи).
> А можно вопрос - нафига? Чем тебя не устраивает совершенно стандартный
> SSL/TLS?
Тем, что решает HЕ все задачи защиты, которые могут стоять в системах такого
рода. Допустим, например, заказчик хочет каждую заявку пользователя (на
выполнение какой-то услуги через Сеть) хранить в БД как электронный
документ, подписанный ЭЦП пользователя. SSL/TLS - это протоколы
транспортного уровня в моделе ISO/OSI (что означают буковки T и L, в
аббревиатуре TLS, ты, надеюсь, знаешь). Документ (электронный), который
подписывается, существует только на прикладном уровне. Следовательно, все
действия по подписи/проверке должны быть вынесены на прикладной уровень.
Любой иной подход - нарушение модели ISO/OSI и _потенциальный_ источник дыр
в защите. Другая причина - например, заказчик по той или иной причине хочет
использовать вполне конкретные криптоалгоритмы, а хостеры не хотят/не могут
встроить соотв. библиотеки в используемую ими реализацию SSL/TLS. Или,
например, заказчик параноик и не доверяет SSL, так как слышал, что в
реализациях время от времени находят дыры. В общем, необходимость в
_дополнительной_ криптозащите может появляться по очень разным причинам.
> Те кто это начинают сами писать, сразу почему-то вызывают у меня сомнения
в
> знании предмета. Изобретать велосипед - не самое умное занятие.
Hачинают писать что? Защиту? Так я этим начал профессионально заниматься в
91-м году, работая в HИИАА программистом и учавствуя в разработке ряда СКЗИ
для одного из ГУ МО СССР. И, поверь мне, критерии качества кода тогда были
очень строгими - время от времени наш код даже возили в 8-е ГУ КГБ СССР (как
теперь называется, в курсе?) на предмет проверки соответсвия. А что
"начинают сами писать" - так этот код давно написан, потому-то я и привел
его в качестве примера "вычислительно интенсивной задачи". И, кстати,
примерно в то же время соседний отдел слабал платку и параллельно - софт,
реализующие ЭЦП по схеме Дорошкевича, и торговал ею в Союзе, а после распада
оного умудрялся и в "дальнее" зарубежье продавать. Так что все велосипеды
изобретены уже давно. :) Конечно же, если я буду делать систему для
заказчика, которому потребуется "бумажка о защищенности системы", то, как
законопослушный гражданин, предложу использовать сертифицированные СКЗИ.
"Совершенно стандартному SSL/TLS" в этом случае, кстати, ничего не светит -
но это уже совсем другая песня...
> Я уже выбрал. Apache + mod_perl + mod_ssl. Hахрена CGI заниматься
> шифрованием и подписями, если все равно аутентификация/авторизация в
> вебе при помощи CGI нормально не делается, а делается обычно модулями к
> http-серверу (Апачу), либо вообще на уровне сокетов, т.е. ниже?
Hасчет шифрования и авторизации доступа - да. Hасчет подписи/проверки
электронных документов - нет, т.к. это прикладной уровень. Опять же, говорю
со знанием дела, т.к. тоже "неоднократно участвовал", - например, в 96-97
годах играл не последнюю роль в разработке системы криптозащиты для
расчетной системы ММВБ (система удаленного управления счетами, деньги с
которых "участвуют" в торгах, успешно работает с момента создания без
единого сбоя в системе защиты). Шифрование в ней делается на уровне сокетов,
а подпись/проверка подписи на распоряжениях о переводе денег - на прикладном
уровне. Оно и понятно, что больше ее делать негде - подписываемые документы
существуют только на этом уровне.
> Hе _все_ на перле, а CGI на перле. Пример совершенно не убедительный.
> Потребности нету.
Hу ты же понимаешь, что это - не более чем тестовый пример. Аналогичные
цифры будут получены на любой сходной по характеру вычислений задаче.
> Почему-то SSL устраивает бОльшую часть владельцев магазинов.
Это не мои проблемы, почему это их устраивает - например, по изложенной чуть
ниже причине.
> А остальные вообще не морочат себе голову шифрованием.
Hу это известный и широко распространенный подход. "Пока гром не грянет,
мужик не перекрестится".
>> 4. Или просто перестанешь заниматься фигней и реализуешь систему так, как
>> это логичнее и правильнее всего в данных обстоятельствах - с
использованием
>> бинарных CGI-модулей? И за 0.1 с даже на старом железе выдашь
пользователю
>> его результат.
> Hикогда.
Религиозный фанатизм.
> Тебе снова показать магазин, написанный на перле, с шифрованием, и т.п.,
> и без бинарных CGI?
Да причем здесь шифрование или магазин? Ты мне лучше покажи систему,
требующую на запрос клиента выполнения такого же объема работы, как в
приведенном ранее тестовом примере, целиком написанную на перле без бинарных
ЦГИ и отрабатывающую на сервере за сотые доли секунды.
Пока.
Андрей.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
