res2001,
>видимо они передаются при подключении клиента
Конечно, само собой. Открытый ключ клиента точно передается, закрытый может использоваться для подписи челленжа - стандартная история - но конкретику надо смотреть отдельно в этом моменте.
>Пока соединения нет - не знает, но в процессе подключения клиента - уже знает.
А, окей, мы просто друг друга не поняли. Разумеется, я имел в виду в "холодном" состоянии.
res2001, про список отзыва я написал просто в самом начале первым же ответом.
Ты же писал про синхронизацию клиентских ключей - а она просто не нужна, ни в отношении открытых, ни в отношении закрытых.
>но в жизни часто это не так.
Ага, но это только то, что касается наших гос. УЦ - в жизни. В реальной. А в онлайновой, так сказать, все вполне соответствует чаще, чем не соответствует.
res2001, читай внимательно что тебе пишут, а писал я тебе про ovpn-сервер, а не про PKI. Центру сертификации необходимо знать, какие сертификаты им выпущены. Тому, что лишь проверяет подпись центра сертификации - в данном случае это OVPN сервер - этого знать не нужно.
И нет ни малейшего смысла тащить PKI вместе с CA, его закрытым ключом, и списком сертификатов им выпущенных, на второй сервер.
Что касается OSCP - не обязательно. В свойствах сертификата указываются точки распространения списка отзывов (CDP), и разные реализации PKI могут уметь (а могут не уметь) выгружать CRL полностью через них, причем вариации протоколов ограничены только возможностями PKI - хоть самба, хоть http, хоть нфс - что умеет, в общем. А сам OSCP не про списки отзывов как таковые, в общем то.
OVPN-сервер ничего не знает о клиентских ключах, и знать не должен. Знает только PKI. OVPN серверу надо знать только сертификат CA и список отзыва, но не клиентские ключи и сертификаты.
iCpu, лучше к драйверам присмотритесь, в том числе кардридера. Аппаратная неисправность кардридера едва ли может влиять на I/O операции других накопителей, а ошибки драйвера могут, причём не обязательно драйвера кардридера.
Владимир Юрченков,
щито, простите?
Я не знаю какую имплементацию OVPN и PKI вместе с ним вы используете; в стандартизированной терминологии, оторванной от конкретных реализаций - я расписал как что и зачем. Если в используемом вами PKI вместо CRL есть некие index-файлы с некими R метками - мне об этом ничего неизвестно.
В норме CRL должны быть подписаны закрытым ключом CA точно так же, как и выпускаемые этим CA сертификаты. Но может в случае OVPN в той реализации, которую вы используете, будет достаточно простого списка - не знаю.
Во-первых, что ты называешь ждущим режимом?
Во-вторых, включение/отключение монитора обычно не триггерит кхм, "звук". Скорее поверю, что случайным или не очень образом засыпают/просыпаются usb-порты
dumasti, он у вас может от группы рута работать, а не от пользователя, а на каталоге может не стоять разрешений для группы. Разбирайтесь с правами доступа в общем.
tempick, ну, наверное, но не со стандартными виндовыми api. Electron какой-нибудь так умеет, наверное, но тут я на самом деле не разбираюсь. В любом случае, так или иначе зависит это от приложения. В случае винды, по крайней мере. Что там с иксами - без понятия.
VasyaID, ну конечно всегда есть вероятность ошибки, но практика работы с конечными пользователями подсказывает, что в данном случае эта вероятность очень невелика :))
VasyaID, да в целом понятно о чём он говорит и без уточнений. Просто практика работы с конечными пользователями подсказывает. Другой вопрос, что совсем уж элементарного решения нет, а не элементарное уже расписали в ответах.
Ну вот представь, что можно принудительно задать размер окна извне.
Далее возникает вопрос: а кто телеге будет сообщать, что надо в окне оставить только поле ввода сообщения, а другие элементы убрать?
О скрытии отдельных элементов при таком-то размере окна приложение не знает, если в нём это не прописано, бесконечно уменьшать не может, а возможность прокрутки внутри окна тоже определяется самим приложением. В такой ситуации как можно принудительно задавать размер окна извне?
VasyaID, нет, у него просто напросто вход через аккаунт microsoft, и смена материнки, очевидно, вышибла его систему из авторизованных, что повлекло неработоспособность и пинкода, который можно установить для входа вместо пароля. А сети нет, потому что дров нет.
VasyaID,
>Я в курсе как работает mitm-proxy. Я его даже юзаю изредка для анализа траффика.
был бы в курсе - не писал бы того, что пишешь, и не удивлялся бы банальным вещам.
>Пожалуй на этом можно и закончить :)
Ну, если тебя смущает слово "самоподписанный" - так это всего лишь от непонимания того, как это работает. Любой корневой сертификат CA подписан закрытым ключом от своей собственной пары. Это просто задаёт первое звено в цепочке доверия, не более (случаи с перекрёстной подписью не рассматриваем, это за рамками обсуждения). Любой сертификат, который ты обнаружишь в хранилище корневых сертификатов винды при чистой установке - самоподписанный. Да-да, и все эти VeriSign, и Microsoft Root, и прочее.
Ты всё, очевидно, цепляешься за коннотации, сопутствующие словам "корневой", "самоподписанный", и т.д., но не стоит этого делать. Это всё сугубо технические термины.
И то, что каспер может влезть своими лапами куда угодно, как и потенциально любой софт с привилегиями администратора в системе - тоже ничего особо удивительного. Тем более, что KIS как таковой специально затачивается на отлов всех возможных внешних доступов с машины. Понятно, что он и хранилище portable фаерфокса найдёт, и влезет в него. Ну, как бы, что мешает то? Впрочем, особо хитрые (шифрованный образ+vm) portable-образы действительно могут этого избежать, но кто-то такими заморачивался?
Да и то, что любой софт, подобный KIS, создаёт дополнительные векторы атаки - тоже дааааавно не секрет. Они не могут работать по-другому. Вопрос лишь в балансе безопасности и функционала - как всегда.
>видимо они передаются при подключении клиента
Конечно, само собой. Открытый ключ клиента точно передается, закрытый может использоваться для подписи челленжа - стандартная история - но конкретику надо смотреть отдельно в этом моменте.
>Пока соединения нет - не знает, но в процессе подключения клиента - уже знает.
А, окей, мы просто друг друга не поняли. Разумеется, я имел в виду в "холодном" состоянии.