Б....ь, все вопрос закрыт. Они мало того что имеют клиентский сертификат, так еще и используют его...
$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]


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

Так и есть.


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

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