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

← →
sniknik © (2016-04-19 13:23) [0]

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

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

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

← →
KilkennyCat © (2016-04-19 13:56) [1]

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

← →
KilkennyCat © (2016-04-19 13:58) [2]

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

← →
DVM © (2016-04-19 14:02) [3]

> sniknik © (19.04.16 13:23)

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

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

← →
KilkennyCat © (2016-04-19 14:04) [4]

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

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

← →
sniknik © (2016-04-19 14:14) [5]

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

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

← →
sniknik © (2016-04-19 14:17) [6]

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

← →
sniknik © (2016-04-19 14:24) [7]

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

← →
KilkennyCat © (2016-04-19 14:26) [8]

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

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

← →
DVM © (2016-04-19 14:52) [9]

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

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

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

← →
sniknik © (2016-04-19 14:54) [10]

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

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

← →
sniknik © (2016-04-19 14:58) [11]

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

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

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

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

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

← →
дапофик © (2016-04-19 15:11) [13]

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

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

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

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

← →
DayGaykin © (2016-04-19 15:23) [14]

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

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

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

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

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

← →
sniknik © (2016-04-19 15:25) [15]

> смотреть здесь: 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 © (2016-04-19 15:29) [16]

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

← →
sniknik © (2016-04-19 15:32) [17]

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

← →
дапофик © (2016-04-19 15:33) [18]

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

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

← →
DVM © (2016-04-19 15:39) [19]

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

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

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

← →
sniknik © (2016-04-19 15:40) [20]

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

← →
sniknik © (2016-04-19 15:42) [21]

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

← →
DVM © (2016-04-19 15:43) [22]

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

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

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

← →
DVM © (2016-04-19 15:46) [23]

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

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

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

← →
sniknik © (2016-04-19 15:46) [24]

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

← →
дапофик © (2016-04-19 15:49) [25]

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

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

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

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

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

← →
sniknik © (2016-04-19 15:49) [26]

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

← →
DVM © (2016-04-19 15:55) [27]

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

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

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

← →
DayGaykin © (2016-04-19 15:59) [28]

> $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:08) [33]

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

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

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

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

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

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

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

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

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

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

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

Так и есть.

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

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

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