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

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

Сам не Одмин, и не безОпасник, но... от них, ИМХО, больше проблем чем пользы.
В общем возможна на сервере/Апаче настройка которая бы сохраняла id/подпись сертификата под которым был проведен запрос?

если используется mod_ssl, то да, сustom log есть, можно записать кучу всяких SSL_CLIENT_*

к сожалению, я уже не помню как.
смотреть здесь: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html - "Environment Variables" и "custom log format"

> sniknik ©   (19.04.16 13:23) 


> "вы мне на сервере покажите, что это именно под моим сертификатом
> запрос был"...

А чего он хочет увидеть собственно? Запись в лог файле? И что там должно быть написано?
Это же по сути текстовый файл, туда что угодно можно написать. А вот факт соединения - доказательство ибо нет сертификата, нет соединения.

> DVM ©   (19.04.16 14:02) [3]
> А вот факт соединения - доказательство ибо нет сертификата,
>  нет соединения.

разве? мне казалось, соединение будет, но не будет защищенным. По крайней мере, я так недавно обходил отсутствие сертификаты.

> А чего он хочет увидеть собственно? Запись в лог файле? И что там должно быть написано?
Что типа цифровой подписи от клиента, по которой однозначно идентифицируется именно его сертификат (а не например выданный нашим же админом своему другу дубль...). Хз. как он себе это представляет (потому как там даже дубль не будет работать, не соединение пройдет, но вот дальше... там еще цепочка менеджеров/идентификаторов/настроек по к которым уже у админа доступа нет... не должно быть).

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

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

> смотреть здесь:
Отправил админам... посмотрим поможет ли.

> sniknik ©   (19.04.16 14:17) [6]

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

> sniknik ©   (19.04.16 14:14) [5]


> Да вот как-то эту самую простую мысль не могу "донести"
> до нашего же безОпасника

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

> в их трактовке получается наличие сертификатов вообще бессмысленно.
Ну да, а вот подпись сделанная тем же самым сертификатом типа "решает". Нонсенс.

> логируй все подряд
Да практически так и есть, и в логах видно "взлом" сети (в кавычках потому как для нашего ПО это штатный вход, с нормальным зарегистрированным логином/паролем, т.е. может и не взлом, может кассир отошел не разлогиниваясь, а кто-то воспользовался). Единственно, что можно посчитать проблемой, это платежи сделаны, по логам, из под удаленного рабочего стола... НО!!! Они там все так работают, местный админ посчитал это более правильным и настроил разрешения (по умолчанию RDP запрещен).

> Алгоритм ГОСТ, криптопровайдер встроенный в ключ сертифицирован
Это у нас "по желанию", клиент решает какой ему сертификат "ближе к сердцу". В данном случае речь о RRS X.509.

> подписать можно только имея физический ключ.
Он чего-то там стоит, агенты этого не любят. Хотя, даже файловый можно записать на флешку и будет по логике тоже самое. Но думать они не любят также.

клиент браузерный или полноценный?

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

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

ну допустим найдете вы в логах апача, что такой-то запрос, такого-то числа с такого-то ип был подписан сертификатом с таким то серийником и таким-то отпечатком и чего?

так это же лог и вы его руками нарисовали.
вот вы мне покажите мой запрос и моё эцп к нему.

это я говорю с тз вашего возбухшего клиента

Пакеты, которые приходят от клиента не шифруются с помощью закрытого ключа клиента, а шифруются сессионным ключем. Этот сессионный ключ генерируется вначале SSL сессии с помощью протокола Диффи-Хеллмана, а с помощью закрытых ключей подтверждается (помимо прочего).

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

Поэтому тебе нужно самому подписывать клиентским сертификатом запрос и отправлять подпись вместе с запросом. А на сервере записывать все запросы и подписи.

Это не сложно реализовать, если клиент - твое нативное приложение.

HTML+JS, насколько я знаю, не может подписывать формы. Но это ИМХО, т.к. никогда передо мной такой задачи не стояло. Есть какой-то https://www.w3.org/TR/WebCryptoAPI/ (поддержка: http://caniuse.com/#search=Web%20Cryptography ) , посмотри, можно ли с помощью него можно подписать именно клиентским сертификатом.

> смотреть здесь: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html - "Environment Variables" и "custom log format"
SSL_CLIENT_CERT  string  PEM-encoded client certificate
Это что весь клиентский сертификат на сервере получить можно? Или я не понял чего?
Но вообще, если так, то большего желать нельзя...

> то надо было не канал закрывать сэсээлем,
Бесполезно обсуждать что было бы если бы, и как надо было делать... как делать тоже не потолка прилетело, сделано так как заказывали.

> Это не сложно реализовать, если клиент - твое нативное приложение.
Клиент мое, сервер нет. И даже если я добавлю подпись (хотя имхо это лишнее) на клиенте,  то на сервере ее проверять/писать некому... да и не пройдет запрос с какими то доп параметром, там они режется по проверочному регекспу.

> либо придется хранить сессионный ключ и его подпись
Это стандартная вещь на сервере? "Раскрутить" до определения собственно сертификата/ключа клиента можно?

с логами грамотные юристы вас отправят погулять куда-нибудь

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

> sniknik ©   (19.04.16 14:58) [11]


> Хотя, даже файловый можно записать на флешку и будет по
> логике тоже самое.

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

Б....ь, все вопрос закрыт. Они мало того что имеют клиентский сертификат, так еще и используют его...
$ssl=openssl_x509_parse($_SERVER[’SSL_CLIENT_CERT’]);
И после вытаскивают из него идентификатор агента... Т.е. там двойная гарантия, соединился, распаковал, да еще ID сошелся... Поубивал бы, "мы не подумали". Слов нет. А они по идее этим и занимаются, деньги получают.

> Закрытый ключ должен быть неизвлекаем с носителя и никогда его не покидать
Ты просто не видел защищенных флешек. Я в принципе тоже ;), но меня убеждали что "гарантия", без пароля не прочитаешь.

> DayGaykin ©   (19.04.16 15:23) [14]


> HTML+JS, насколько я знаю, не может подписывать формы.

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

> sniknik ©   (19.04.16 15:42) [21]


> Ты просто не видел защищенных флешек.

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

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

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

этот тезис устарел лет сто как тому.

на флешке не сам ключ, а контейнер ключа.
да хоть на дискете.

и в юзерспейсе библиотеки его из контейнера не извлечь.

а тезис ставит знак равенства между носителем и контейнером

> Не, все равно это другое.
Ну если "докапываться", то да другое. Я с Аладином работал, похожее что-то у них было. А по виду/действию то же самое, пока не украли с паролем вместе доступа нет без физического носителя.

> дапофик ©   (19.04.16 15:49) [25]


> и в юзерспейсе библиотеки его из контейнера не извлечь.

Что одни сумели положить, другие сумеют извлечь. Так что ничего не устарело.
Более того, перед тем как ключ был записан в контейнер, он какое-то время существовал отдельно от него (пусть и оперативной памяти). что уже само по себе ненадежно.

> $ssl=openssl_x509_parse($_SERVER[’SSL_CLIENT_CERT’]);
> И после вытаскивают из него идентификатор агента... Т.е.
>  там двойная гарантия, соединился, распаковал, да еще ID
> сошелся... Поубивал бы, "мы не подумали". Слов нет. А они
> по идее этим и занимаются, деньги получают.

Как это поможет доказать, что именно этот клиент запрс отправил?

в общем все эти разговоры про тупых безопасников - ни о чем.

внутри всем понятно, что запрос делал клиент.
снаружи (в суде) вы логами ничего не докажете.
ибо "так не пишут"

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

а если надо, то безопасность надо строить не на безопасности канала,
а на прикладных данных.

> DayGaykin ©   (19.04.16 15:59) [28]

Он перед эти насколько я понимаю установил TLS соединение с сервером, используя этот же сертификат. Сервер доверяет не всем сертификатам. После установления соединения в переменных сервера хранится этот самый сертификат SSL_CLIENT_CERT, следовательно запрос сделан владельцем этого сертификата внутри TLS соединения.

следовательно запрос сделан

неа.

не следует.

> дапофик ©   (19.04.16 16:05) [31]

поясни

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

вы вообще там серверы меняете как перчатки.
.... чтобы нагреть своими фальшивыми логами честных невинных клиентов.

> дапофик ©   (19.04.16 16:08) [33]

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

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

p.s. Я не про доказательства в суде, там похоже вообще ничего нельзя доказать.

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

> sniknik ©   (19.04.16 16:25) [36]


> Выше писал, что клиентский сертификат при разборе есть,
> используется а значит пишется.

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

> Не, понимаешь в чем дело
Почему не понимаю, понимаю. Но вопрос/претензия была именно о сертификате. Если бы искали логику/смысл то хватило бы и логов клиента, в которых, как изначально написал запросы есть, и ответы на них от нашего сервера... и к клиентским логам мы, сервер, доступа не имеем, и т.д..

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

> sniknik ©   (19.04.16 17:34) [38]


> Вообще насколько понимаю это тоже пара

Так и есть.


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

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

sniknik ©   (19.04.16 17:34) [38]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

кроме того:

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

> Если же закрытый ключ надежно спрятан в каком либо контейнере, ...
Вот этот вариант, как можно криптопро поставить в фай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 можно спрашивать каждый раз перед подписанием документа.
Не, это только для персонального использования... не в конторах. ИМХО.