Можно на сервере определить сертификат клиента?

← →
Игорь Шевченко © (2016-04-19 21:06) [40]

sniknik © (19.04.16 17:34) [38]

Если не секрет, это где такая задница, про которую ты рассказываешь ?

← →
KilkennyCat © (2016-04-19 21:27) [41]

Насчет доказательства в суде... наверное, можно доказать. Понятие "электронный документ" введено еще во времена СССР.
Конечно, если просто прийти и сказать: "Здрастье, я вот тут лог вам принес" - не прокатит.
Но пропись в договоре между клиентом и конторой строчки типа "фактом выполнения сделки является запись в логе" - уже можно приходить с логом и говорить "здрасьте".
Хотя, конечно, это решение случившейся уже ситуации не поможет.

← →
дапофик © (2016-04-19 21:34) [42]

договоры имеют свойство признаваться юридически ничтожными.

лог не проверишь.
а проверять можно тока подписанный блоб

← →
KilkennyCat © (2016-04-19 22:13) [43]

> дапофик © (19.04.16 21:34) [42]
> договоры имеют свойство признаваться юридически ничтожными.
>

не во всех случаях-то. нельзя прийти и заявить их ничтожными

← →
KilkennyCat © (2016-04-19 22:15) [44]

и в данном случае не прокатит: нет нарушений и обе стороны согласились признать электронный лог подтверждающим документом.
Это не я придумал - юридическая практика работы с электронными документами в нашей стране.

← →
дапофик © (2016-04-19 22:27) [45]

я ж и говорю.
что "внутри" всем и так ясно.

но.
если дойдет до дела, то логи не прокатят.

грамотный юрист победит и ваши логи и пунктики договора.

поетому, если вы согласны с тем, что достаточно того, что "ну мы же договаривались верить друг другу" то логи и пункты вообще не нужны.

достаточно просто заявить клиенту ничем не аргументируя "у нас все верно, мы знаем что это делали вы"

← →
sniknik © (2016-04-19 22:39) [46]

> Если не секрет, это где такая задница, про которую ты рассказываешь ?
Киви, а вот агента не знаю, банк какой то.

← →
дапофик © (2016-04-19 22:41) [47]

вот мы например встретились пока не в суде.

я (клиент): я этого не делал
вы : вы делали это, у нас есть лог и мы договаривались верить логу
я : я логу вашему верю как и указано в договоре. НО! я не верю что ваш лог это ваш лог.

вы : но это наш подлинный лог!
я: фик то правда, лог подделан вашими ойтишниками, которые вас обманули выдав его за подлинный. Но подлинному логу я бы поверил!

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

тупик.
идем в суд.

судья мне : какие ваши доказательства что лог подделан?
я судье : в логе написано то, чего я не делал. лог поддельный.
судья вам : где ваш подлинный лог?

← →
sniknik © (2016-04-19 23:00) [48]

> нет нарушений и обе стороны согласились признать электронный лог подтверждающим документом.
Кстати не факт, ни одного договора не видел (не мое дело), и потому х.з. что там они признают...
Вот то что мое, я формирую при запросе на сертификат "Акт признания открытого ключа", что бы это ни значило (предыдущие безопасники, которые собственно выдумывали эту систему, говорили что по нему определяется ВСЕ, хотя он вроде посылается на сервер чтобы сертификат сгенерить с привязкой к корневому)... ну вот в документ вставляются части ключа - RSAKey, Prefix, Modulus, Postfix, Exponent, и его точно должны подписать обе стороны. Но опять таки, должны и делают... х.з. в общем, я это контролировать не могу.

> заявить клиенту ничем не аргументируя "у нас все верно, мы знаем что это делали вы"
Аргумент в виде логов от самого клиента в которых запросы есть это "ничем не аргументируя"?

> грамотный юрист победит и ваши логи и пунктики договора.
Грамотный юрист вообще все победит, ему закон, логика и здравый смысл не писан, и давайте закончим на этом про юристов. В суд обращения не было, и вряд ли будет.

← →
sniknik © (2016-04-19 23:05) [49]

> какие ваши доказательства что лог подделан?
Вообще про логи это хрень, вот то что у сервера ПОЛУЧИЛОСЬ расшифровать зашифрованное клиентом, парными ключами, вот это доказательство, как выше писали. Иначе, если это не так, то вся система сертификатов скомпрометирована, и ничему вообще верить нельзя.

← →
дапофик © (2016-04-19 23:12) [50]

вот то что у сервера ПОЛУЧИЛОСЬ расшифровать

ничего это не значит.
и ничего из этого не следует.

просто бай дезайн.

"неотрицание авторства" - за это дело шифрование/дешифрование никогда и ни у кого не отвечало.

← →
дапофик © (2016-04-19 23:14) [51]

вот то что у сервера ПОЛУЧИЛОСЬ расшифровать зашифрованное клиентом, парными ключами, вот это доказательство,

стопанули сервак, подменили серверу корневой, сделали фальшивый сеанс, снова стопанули, вернули все в зад, запустили снова.

делов-то, хоспади.....

← →
дапофик © (2016-04-19 23:17) [52]

В суд обращения не было, и вряд ли будет.

тогда все вопросы про как определить что-то там у клиента бессмысленны.
достаточно сказать "у нас все верно"
это будет то же самое что тыкать какими то записями каких-то там логов, делая умное лицо при этом.

← →
DVM © (2016-04-20 07:15) [53]

Кстати, сейчас многие банки практикуют подтверждение платежей по смс. Так вот это тоже юридической силы не имеет. Силу имеет только подпись сертификатом выданным сетифицированным УЦ, например Госуслугами или криптопро.
Но тем не менее как то все работают.

← →
sniknik © (2016-04-20 09:03) [54]

> что-то там у клиента бессмысленны.
Я где-то там выше писал смысл - отмазаться от бессмысленной работы. Тут как, есть проблема значит надо решать, и назначают кто это будет решать (хотя бы на уровне советов решающим) вот те самые люди которые как выясняется даже принципов работы НАШЕЙ части не знают, но уже надавали с десяток бредовых рекомендаций переделки ПО клиента, к которому претензий вообще нет и быть не может при штатной работе на ПО злоумышленника, какие претензии? А они начинают выдумывать (ковыряя в носу... так и представляется :) схемы как отличить нормальный платеж от такого же но несанкционированного, или как защитится от кражи сертификата локальным админом который его запрашивал и устанавливал у клиента (рекомендации менять сертификаты после увольнения отвечающего за это админа есть, но ими не пользуются, и от этого защитится, нда)... было бы смешно, если бы не шанс, что мне это поставят после в реализацию.

> Но тем не менее как то все работают.
Именно что как то... дойдет до суда и любая схема "рухнет". Кстати криптопро самый не надежный сертификат, там тоже навернуто дофига поверх, но их единственные как то переносят с компа на комп (домой например). Может конечно потому как распространенные, массовые в денежной сфере, и есть наработки, но по факту у нас еще не было проблем от самопальной привязки к компу, а вот гостовские копировали и даже не админы, от этих вообще защиты нет если попадется "гнилой".
не знаю как копировали, я сталкивался только с последствиями/коственными фактами типа платеж по единственно выдававшемуся сертификату с компа с другим IP, и агент не поставил ограничения что принимать только с одного.

← →
KilkennyCat © (2016-04-20 09:15) [55]

> Силу имеет только подпись сертификатом выданным сетифицированным
> УЦ, например Госуслугами или криптопро.

Нет. Точнее, не только и не во все случаях.
подробнее в Федеральный закон от 06.04.2011 N 63-ФЗ (ред. от 30.12.2015) "Об электронной подписи"
но в общих чертах: есть понятие простой электронной подписи: Простой электронной подписью является электронная подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом.
кроме того: Электронная подпись и подписанный ею электронный документ не могут считаться не имеющими юридической силы только на том основании, что сертификат ключа проверки электронной подписи выдан в соответствии с нормами иностранного права.

← →
дапофик © (2016-04-20 09:18) [56]

Но тем не менее как то все работают.

это случай с дбо для физиков и это случай когда всем объективно "надо"

с одной стороны физикам дбо нужно и это правда.
с другой стороны никто не хочет заморачиваться с десктопным клиентом для физиков в том числе они сами и значит у них там браузерный клиент.
с третьей стороны нормального крипто-решения для прикладного уровня в браузерах нет.

либо ограничиваться ie + capicom + win, либо напрягать яваапплетами

но так как "надо" то все ограничиваются защищенным каналом смс"ками и прочими костылями.

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

← →
sniknik © (2016-04-20 10:28) [57]

Удалено модератором
Примечание: Выражения выбираем

← →
sniknik © (2016-04-20 10:33) [58]

> не знают что и как работает
Кстати они похоже и думали так же как и ты... имхо, по косвенным признакам (клиентские логи запросили только через 2 недели, я попросил их через неделю... сразу как подключили к проблеме). По моему показатель. Хотя это и оффтопик уже.

← →
DVM © (2016-04-20 13:41) [59]

> sniknik © (20.04.16 09:03) [54]

> Кстати криптопро самый не надежный сертификат, там тоже
> навернуто дофига поверх, но их единственные как то переносят
> с компа на комп (домой например). Может конечно потому как
> распространенные, массовые в денежной сфере, и есть наработки,
> но по факту у нас еще не было проблем от самопальной привязки
> к компу, а вот гостовские копировали и даже не админы, от
> этих вообще защиты нет если попадется "гнилой".

Ну по поводу копирования сертификата (точнее закрытого ключа, сам сертификат это не секрет) все зависит от того, где и как формировался этот самый закрытый ключ и делался запрос на выдачу сертификата для этого ключа.
Если просто использовали какую нибудь OpenSSL и закрытый ключ валяется на диске после этого, то утащить или перенести куда либо его не проблема.
Если же закрытый ключ надежно спрятан в каком либо контейнере, доступ к которому запрещен операционной системой и крипто-преобразования она выполняет сама с этим ключом, тогда при переносе могут быть сложности. Но это тоже решаемо, хоть и неудобно. Удобнее всего имхо внешние носители с неизвлекаемым ключом и встроенным криптопровайдером, типа JaCarta.

← →
DVM © (2016-04-20 13:45) [60]

> дапофик © (20.04.16 09:18) [56]

> с третьей стороны нормального крипто-решения для прикладного
> уровня в браузерах нет.

Есть кое-что. Вот например: http://www.aladdin-rd.ru/solutions/jcwebclient/
Никаких Java апплетов и плагинов (ибо все браузеры позакрывали NPAPI)
Работает примерно как я описал в [22]. Т.е на компьютере пользователя ставится доп. ПО.
Конечно было бы лучше всем, если бы производители браузеров сделали нормальный API для таких дел.

← →
дапофик © (2016-04-20 14:19) [61]

да фигня это.
работает на винде оунли, хотя препятствий никаких нет, но они сделали только для винды
для установки таки нужны права а я хочу сделать это зайдя в инет кафе.

такой же точно велосипед был у меня лет 9 назад.

← →
дапофик © (2016-04-20 14:38) [62]

а еще эта штуковина думает, что если проксик забиндил только 127.0.0.1, то он как бы в домике.

и вот работает с ним законный интерактивный юзер, плюс юзер в рдп, плюс юзер в внц.
и все порождают каждый свои документы и у которых будет эцп того, кто воткнул флешку.

← →
DVM © (2016-04-20 15:04) [63]

> дапофик © (20.04.16 14:38) [62]

Не будет проблем, надо еще PIN код устройства ввести. Устройств может быть воткнуто несколько, можно выбрать свое.

← →
sniknik © (2016-04-20 15:31) [64]

> Если же закрытый ключ надежно спрятан в каком либо контейнере, ...
Вот этот вариант, как можно криптопро поставить в файk на диск, я даже не знаю как, и практически гарантия не делается.

> Но это тоже решаемо, хоть и неудобно.
Интересно как? Случаи были при установке сертификата в виндовый реестр (ну или куда он его в этом случае ставит, я при работе указываю адрес реестра CURRENT_USER\MY\ или LOCAL_MACHINE\MY\). С "железным" вариантом само собой проблем нет... хотя их ОЧЧЕННЬЬ мало этих вариантов, может поэтому. Спереть "флешку", особенно если они в твоем ведении, ты заказываешь, имхо тоже не проблема. Ведь работает не один кассир, а... ну вот одни есть, у них 400 точек, заказать ключей 410 с излишком под "брак" - вуаля.

> или куда он его в этом случае ставит
Там когда его генеришь вызывается функция самого криптопро (он это криптопро), и у нас даже предупреждение есть - не использовать виндовый мастер при установке, т.к. он не связывает ключ с контейнером и в результате сертификат получается нерабочим.

> sniknik © (20.04.16 15:31) [64]

> Спереть "флешку", особенно если они в твоем ведении, ты
> заказываешь, имхо тоже не проблема. Ведь работает не один
> кассир, а... ну вот одни есть, у них 400 точек, заказать
> ключей 410 с излишком под "брак" - вуаля.

Ну это же не просто флешки, информацию с одной на другую не скопируешь.
При серьезном подходе к выдаче сертификатов вариант заказать N сертификатов про запас не катит, ибо:

1) Запрос на сертификат генерируется аппаратно устройством и передается в УЦ.
2) УЦ выпускает такие сертификаты согласно заявлению, по паспорту и т.д. Т.е нельзя их выдавать кому попало и по 5 штук в руки про запас.
3) Сертификат кладется только на то устройство, которое сгенерировало запрос, иначе бессмысленно (хотя и можно), подписывать же будет пара закрытый ключ + сертификат, а закрытый ключ лежит на устройстве и его оттуда нельзя считать и скопировать.
4) При утере/краже флешки немедленно следует запрос в УЦ на отзыв сертификата и серьезный софт должен проверять, а не отозван ли сертификат который ему пытаются подсунуть. Утерявший сертификат возвращается на пункт 1) с новым закрытым ключом в новом устройстве.

> sniknik © (20.04.16 15:31) [64]

> > Но это тоже решаемо, хоть и неудобно.
> Интересно как? Случаи были при установке сертификата в виндовый
> реестр (ну или куда он его в этом случае ставит, я при работе
> указываю адрес реестра CURRENT_USER\MY\ или LOCAL_MACHINE\MY\).
>

Как я уже писал выше, что одни сумели положить. другие сумеют достать. Вся информация лежит на жестком диске, который всегда можно прочитать загрузившись из другой системы или с LiveCD/флешки. Ключ шифрования лежит там же. Единственное если контейнер запаролен, то нужно знать пароль, чтоб достать оттуда закрытый ключ, но запаролленные контейнеры обычно создаются для экспорта сертификатов с закрытым ключем, в повседневном использовании они не запаролены.

т.к. он не связывает ключ с контейнером и в результате сертификат получается нерабочим.

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

самом собой привязка не будет действовать если сертификат сам по себе в виде например файла.

> При серьезном подходе
Не вижу ничего особо серьезного в написанном, что позволило бы избежать потерь... при краже любого сертификата/гост/rsa/железа/х.з. что платежи по нему останавливаются, по первому обращению, как заметят, это час-два. Бывает и дольше, даже месяцы, когда кто-то делает мелкие проводки в надежде что не заметят, а крупные конторы и не замечают. Но это редкость, и обычно свои, изнутри, их ловят. При внешних взломах (вот как тут) пытаются максимально быстро перевести деньги агента и вывести их, иначе отменами все вернут назад.

Ну и чем поможет какой то внешний УЦ? Или расписанные действия, да пока вы по ним с центром свяжетесь у агента уже денег не останется, и на этом все естественным образом закончится... (денег держат обычно на один операционный день +- "от щедрот"). Лишний геморрой только.

> sniknik © (20.04.16 16:25) [69]

> Не вижу ничего особо серьезного в написанном

Там описана стандартная последовательность действий при работе с сертификатами. Главное - аккуратность. А для раздолбаев, которые теряют аппаратные ключи вводится двухфакторная авторизация, помимо аппаратного ключа с сертификатом еще добавляется еще пара логин/пароль, привязанная к открытому ключу сертификата. Т.е сразу быстро так деньги не украдут. А потом сертификат и заблокируют.

> А потом сертификат и заблокируют.
Мы сами блокируем свои сертификаты, максимально быстро, а "раздолбаи" это наши агенты. Все что ты написал это может и хорошо, но проблемы не решит. Вообще.

Возвращаясь к случаю из-за которого появился топик - ты работаешь на законно установленном ПО, с "аккуратно" выданным тебе сертификатом, аппаратном ключе (пусть все до кучи), на выделенном для этого сервере по RDP (тут "бзик" админа, который тебя/твою работу вроде бы должен защищать).
Вроде все хорошо, но у админа есть свой канал "внешнего RDP" (ну а чё ему каждый день на работу ходить, он все и из дома порешать может).
Ну и вот в один из дней по этому внешнему каналу заходит не админ, с другого компа (из логов программы видно), подключается к твоей сессии, смотрит что ты там на приглашение логин/пароль ввел... запускает ту же прогу (оттуда же! логи клиента от злоумышленника нашли прямо в основной установке!), вводит твой логин пароль, в общем делает то же что и ты но указывает свои реквизиты.
Как ты от этого защитишься? ("железным" сертификатом? да ты же его сам вставил! ты же работаешь)
Чем поможет все написанное, и вообще любые действия, если все что хоть как то могло помешать (ограничится только локальной сетью, не включать RDP, не включать внешние интерфейсы, настроить в кабинете свои ограничения) тем же админом было "любовно" выключено, и/или поставлено * (all), т.к. ему же неудобно, и по всякой ерунде пришлось бы на работу ехать.

> смотрит что ты там на приглашение логин/пароль ввел... запускает
> ту же прогу (оттуда же! логи клиента от злоумышленника нашли
> прямо в основной установке!), вводит твой логин пароль,
> в общем делает то же что и ты но указывает свои реквизиты.
>
> Как ты от этого защитишься? ("железным" сертификатом? да
> ты же его сам вставил! ты же работаешь)

Ты думаешь ты сможешь придумать такие ситуации, о которых другие не подумали? :)

Я уже объяснял. Для доступа к ключу нужно ввести PIN код.
Для особых параноиков или для работы в полностью врадебном окружении есть специальные клавиатуры, ввод с которых не перехватывается просто так: http://www.aladdin-rd.ru/catalog/antifraud/
Для работы с конкретным приложением, оно должно забиндиться на ключ путем ввода пин-кода. Админ не увидит и не перехватит никакого твоего ввода.
PIN можно спрашивать каждый раз перед подписанием документа.

> сможешь придумать такие ситуации
Я не придумал, тут именно так все и произошло. Я только "ужесточил" реальность железным ключом, но без своей клавиатуры на нем, о таком не подумал.

> оно должно забиндиться на ключ путем ввода пин-кода.
Это только чуть усложняет схему, нужно только не запускать новое приложение, а подсоединиться, ну и надеяться, что кассир на обеде например.

Хотя, да это я уже выдумал, такого у нас еще не было.

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

> PIN можно спрашивать каждый раз перед подписанием документа.
Не, это только для персонального использования... не в конторах. ИМХО.

Можно на сервере определить сертификат клиента? Найти похожие ветки