Pull to refresh

Comments 42

Сохраненные запросы сотрудники отправляли по электронной почте мне.


Да знаете, мне как-то пофиг на персональные данные, но куда более интересный вопрос — зачем все это вообще? Ну т.е. я как сотрудник по идее вообще не должен заботиться о том, какие там у кого токены. Единственное исключение, возможно — если ваша политика разрешает подключаться к рабочему VPN с персонального устройства, да и то сомнительно. У каждого сотрудника и так должен быть свой рабочий логин\пароль (ну там LDAP какой-нибудь же у вас развернут, правда?) и это — единственное, что вы должны требовать для подключения к рабочей сети. Например, как это у нас организовано (очень крупная американская компания, но не FAANG) — доступ к VPN только с рабочих ноутбуков, на каждом ноуте предостановлена утилита от Cisco, из дома запускаешь утилиту, вводишь свой логин-пароль — и она подключает тебя к VPN. Все. Сертификаты, ручные активности, емейлы, прости госсподи — зачем это все?
Сертификаты, ручные активности, емейлы, прости госсподи — зачем это все?

Надо спросить мировое сообщество зачем вообще придумали PKI (Public Key Infrastructure), сертификаты, электронную подпись, когда оказывается есть "логин-пароль".
Поэтому и придумали, что с логин-паролем могут быть проблемы.


мне как-то пофиг на персональные данные

Я не думаю, что это именно так. Если что-то случится неприятное (не дай бог, конечно), то вы будете говорить совсем другое: я не давал права публиковать или использовать мои персональные данные, это не я ставил электронную подпись под договором дарения и т.д. Почитайте материалы на Хабре.

Запилите статью, как вы без паролей живете? И логин в учетную запись операционной системы без пароля, и почта без пароля, и логин в веб-интерфейс системы контроля версий (не путать с git push) без пароля, логин в любую другую софтину Х без пароля? Ключи хороши там, где они работают, но «мировое сообщество» еще очень далеко от отказа от паролей в принципе. И если у вас получилось (в чем я очень сомневаюсь) настроить работу в отдельно взятой компании целиком на ключах, это будет на порядок интереснее почитать, чем про ручную пересылку ключей по емейлу.
как вы без паролей живете?

Легко, имею токен PKCS#11 с сертификатом и без всякого пароля хожу на сайт ГОСУСЛУГ, например. Так что многие и многие живут без пароля, хотя пока он преобладает сегодня. А для входа в ОС есть двухфакторная авторизация: первый рубеж защиты, да, пароль, но второй и надежный предъявление сертификата на токене.


Запилите статью, как вы без паролей живете?

А вообще-то статья про другое, но, если настаиваете, то напишу.

Без паролей живем хорошо. SSO и отпечаток пальца на ноуте для логина в ОС. Весь корпоративный софт должен SSO понимать. Да-да весь не понимающий пора уже заменять на нормальный.

Пароль не вводил наверно никогда. А не вру. С мокрыми руками вводить пришлось разок. Отпечаток никак не читался.
SSO что принимает? Нигде и никогда повторного подтверждения не требует? Вот у нас на работе SSO как бы есть, но на доброй половине корпоративных ресурсов все равно логин-пароль требуется (равно как если заходишь в на страничку в инкогнито-режиме). А десктопных приложений, работающих с SSO так я вообще не видел.
Как вы логинились самый первый раз на ПК, чтобы отпечаток установить?
Как вы логинились самый первый раз на ПК, чтобы отпечаток установить?

Все что потребовалось от нас это закомментировать строку с родной аутентификаций и добавить строку модулем pam_p11_gost.

Кстати, отсутствие https на сайте «Лисси» как-то объясняется?
Ну, с моей точки зрения, распространено мнение, что использование HTTPS является желательным (при работе с чувствительной информацией — обязательным), т. к. позволяет в определённой мере гарантировать идентичность веб-сервера, радикально снижая возможность проведения атак типа «человек посередине».

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

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

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

С этой позиции, использование компанией, предлагающей криптографические решения, незащищённого соединения выглядит странно. Вот мне и интересно, как ситуацию видят те, кто считает её нормальной. Я экспертом ИБ не являюсь, в статьях про HTTPS обычно просто упоминают «защищает от MitM», без статистики. Так что пример «Лисси» для меня любопытен. Не скажу, что пример уникальный, но на Хабре представлен не каждый.
Ну, с моей точки зрения, распространено мнение, что использование HTTPS является желательным (при работе с чувствительной информацией — обязательным), т. к. позволяет в определённой мере гарантировать идентичность веб-сервера, радикально снижая возможность проведения атак типа «человек посередине».

Что тут скажешь? Естественно вы правы. Но есть другой интересны вопрос:- Какой https поднимать? ГОСТ-ый? Но далеко не у всех, а вернее у абсолютного большинства нет поддержки ГОСТ-ого TLS. Тогда не ГОСТ-ый, но мы же в России живем, а еже сами разрабатываем криптосредства. Дилемма, философская, но не техническая, конечно.

На мой взгляд, в идеале веб-сервер должен поддерживать международные криптоалгоритмы и ГОСТ, с предпочтением ГОСТ. Т. о. массовый потребитель получит как минимум защиту на общемировом уровне, а патриотичное ПО сможет обеспечить ещё и идеологически верное шифрование. Я не в курсе, как регистрируются алгоритмы для применения в TLS, но, очевидно, такая регистрация должна быть произведена, и должно быть разработано соответствующее клиентское ПО (браузеры), умеющее в ГОСТ, +опции «предпочитать ГОСТ», «блокировать если не ГОСТ» и т. п. Такое ПО может стать или не стать массовым, но как минимум гос. нишу оно может занять.

В то же время, по-моему, не стоит отказываться от «международного» HTTPS, если не получается ограничить всё ГОСТ-ом. Сколько проектов было загублено подходом «если не идеально, то никак».

Кстати, по ссылке написано:
Доступ к сайту ООО «ЛИССИ-Софт» возможен также по протоколу TLS (TLS-1.0, TLS-1.1 и/или TLS-1.2), как в анонимном режиме по адресу www.lissi.ru, либо soft.lissi.ru ...
У меня не получилось.

Я 20 лет за это ратую, но воз и ныне там.


У меня не получилось.

Я уж не помню почему отключили, но после самоизоляции восстановим

А, ну, если это временное явление, то, в общем-то, вопрос мой снимается.

Я 20 лет за это ратую, но воз и ныне там.
Тут могу только пожелать удачи. Состязание идей выявляет лучшую.
Вот у нас на работе SSO как бы есть, но на доброй половине корпоративных ресурсов все равно логин-пароль требуется

Значит, он у вас там не настроен. Автоматическая аутентификация в веб-интерфейсах на основе Kerberos или NTLM — вещь весьма популярная.

А десктопных приложений, работающих с SSO так я вообще не видел.

1С пойдёт? Она умеет использовать интегрированную аутентификацию Windows. И куча другого софта умеет.

Как вы логинились самый первый раз на ПК, чтобы отпечаток установить?

Например, при помощи Kerberos с PKINIT и носителя ключа.
Значит, он у вас там не настроен.

Что и требовалось доказать

Справедливости ради, иногда организовать SSO довольно трудно. Например, у нас в конторе недавно внедрили такую штуку, как Thingworx, и встала задача настройки на нём SSO. Лучше всего было бы использовать Kerberos, Thingworx является серверным приложением под Tomcat, а Tomcat сам умеет поддерживать Kerberos, но Thingworx не использует подсистему аутентификации Tomcat, у него всё своё, и единственный доступный метод SSO — это SAML. У нас есть свой SAML-провайдер, но документация у Thingworx настолько мутная и недостаточная, что чтобы настроить SAML, мне пришлось возиться с декомпиляцией Java-классов Thingworx и неделю ковыряться отладчиком на специально развёрнутом тестовом сервере. Разобрался, работает.
иногда организовать SSO довольно трудно.

А никто и не говорил, что будет легко.

Ну иногда-то легко. Настройка SSO на новом веб-сервере в условиях развёрнутой AD часто сводится к прописыванию его SPN, что делается одной командой.
SSO что принимает?

Пользователя залогиненного на ноуте.

Нигде и никогда повторного подтверждения не требует? Вот у нас на работе SSO как бы есть, но на доброй половине корпоративных ресурсов все равно логин-пароль требуется (равно как если заходишь в на страничку в инкогнито-режиме). А десктопных приложений, работающих с SSO так я вообще не видел.

Нигде и никогда не требует.
Вам пора вкладываться в обновление инфраструктуры. Декстоп и SSO прямо созданы друг для друга. Да и веб сейчас не очень сложно делается.
Проблемы только с телефонами сейчас есть. Решаемые, но сложнее чем во всем остальном.

Как вы логинились самый первый раз на ПК, чтобы отпечаток установить?

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

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

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

В принципе, почему бы нет? Самое плохое, что может устроить выдавший их УЦ — это внезапно отозвать сертификат.
Многие виды токенов являются только носителями ключей, криптоалгоритмы выполняются основным процессором компьютера

Если говорить о российских криптоалгоритмах, то часто так и происходит. Берется токен и его фактически используют как обычную флэшку с PIN-кодом (например, ruTokenLight). Эти злоупотребляют, как правило, CSP на Windows. При чем, когда такой "ключик" выдается заявителю, то ему об этом не говорят. И порой они искренне считают, что у неизвлекаемый ключ на токене PKCS#11. Да и те, кто генерирует ключевую пару через CSP, порой этого не знают.
Другая проблема токенов, это подная реализация механизмов в соответствии с PKCS v.2.40, ее в полном объеме тяжело найти на токенах:


ГОСТ-овые механизмы

Список механизмов, поддерживаемых токеном LS11SW2016

Mechanism #0
Mechanism: CKM_GOSTR3410_KEY_PAIR_GEN (0x1200)
Key Size: 256-256
Flags: 0x10000 ( CKF_GENERATE_KEY_PAIR )
Mechanism #1
Mechanism: CKM_GOSTR3410_512_KEY_PAIR_GEN (0xD4321005)
Key Size: 512-512
Flags: 0x10000 ( CKF_GENERATE_KEY_PAIR )
Mechanism #2
Mechanism: CKM_GOSTR3410 (0x1201)
Key Size: 256-256
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #3
Mechanism: CKM_GOSTR3410_512 (0xD4321006)
Key Size: 512-512
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #4
Mechanism: CKM_GOSTR3410_WITH_GOSTR3411 (0x1202)
Key Size: 256-256
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #5
Mechanism: CKM_GOSTR3410_WITH_GOSTR3411_12_256 (0xD4321008)
Key Size: 256-256
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #6
Mechanism: CKM_GOSTR3410_WITH_GOSTR3411_12_512 (0xD4321009)
Key Size: 512-512
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #7
Mechanism: CKM_GOSTR3410_DERIVE (0x1204)
Key Size: 256-256
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #8
Mechanism: CKM_GOSTR3410_12_DERIVE (0xD4321007)
Key Size: 512-512
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #9
Mechanism: 0xD4321045
Key Size: 256-256
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #10
Mechanism: 0xD4321046
Key Size: 512-512
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #11
Mechanism: CKM_KDF_4357 (0xD4321025)
Key Size: 256-256
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #12
Mechanism: CKM_KDF_GOSTR3411_2012_256 (0xD4321026)
Key Size: 256-256
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #13
Mechanism: CKM_KDF_TREE_GOSTR3411_2012_256 (0xD4321044)
Key Size: 256-512
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #14
Mechanism: CKM_GOSTR3410_KEY_WRAP (0x1203)
Key Size: 256-256
Flags: 0x60000 ( CKF_WRAP|CKF_UNWRAP )
Mechanism #15
Mechanism: CKM_GOSTR3410_PUBLIC_KEY_DERIVE (0xD432100A)
Key Size: 256-512
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #16
Mechanism: CKM_LISSI_GOSTR3410_PUBLIC_KEY_DERIVE (0xD4321037)
Key Size: 256-512
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #17
Mechanism: CKM_GOST_GENERIC_SECRET_KEY_GEN (0xD4321049)
Key Size: 32-256
Flags: 0x8000 ( CKF_GENERATE )
Mechanism #18
Mechanism: CKM_GOST_CIPHER_KEY_GEN (0xD4321048)
Key Size: 32-32
Flags: 0x8000 ( CKF_GENERATE )
Mechanism #19
Mechanism: CKM_GOST_CIPHER_ECB (0xD4321050)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #20
Mechanism: CKM_GOST_CIPHER_CBC (0xD4321051)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #21
Mechanism: CKM_GOST_CIPHER_CTR (0xD4321052)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #22
Mechanism: CKM_GOST_CIPHER_OFB (0xD4321053)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #23
Mechanism: CKM_GOST_CIPHER_CFB (0xD4321054)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #24
Mechanism: CKM_GOST_CIPHER_OMAC (0xD4321055)
Key Size: 32-32
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #25
Mechanism: CKM_GOST_CIPHER_KEY_WRAP (0xD4321059)
Key Size: 32-32
Flags: 0x60000 ( CKF_WRAP|CKF_UNWRAP )
Mechanism #26
Mechanism: CKM_GOST_CIPHER_ACPKM_CTR (0xD4321057)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #27
Mechanism: 0xD4321058
Key Size: 32-32
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #28
Mechanism: CKM_GOST28147_KEY_GEN (0x1220)
Key Size: 32-32
Flags: 0x8000 ( CKF_GENERATE )
Mechanism #29
Mechanism: CKM_GOST28147 (0x1222)
Key Size: 32-32
Flags: 0x60300 ( CKF_ENCRYPT|CKF_DECRYPT|CKF_WRAP|CKF_UNWRAP )
Mechanism #30
Mechanism: CKM_GOST28147_KEY_WRAP (0x1224)
Key Size: 32-32
Flags: 0x60000 ( CKF_WRAP|CKF_UNWRAP )
Mechanism #31
Mechanism: CKM_GOST28147_PKCS8_KEY_WRAP (0xD4321036)
Key Size: 32-32
Flags: 0x60000 ( CKF_WRAP|CKF_UNWRAP )
Mechanism #32
Mechanism: 0xD432105A
Key Size: 32-32
Flags: 0x60000 ( CKF_WRAP|CKF_UNWRAP )
Mechanism #33
Mechanism: CKM_GOST28147_ECB (0x1221)
Key Size: 32-32
Flags: 0x60300 ( CKF_ENCRYPT|CKF_DECRYPT|CKF_WRAP|CKF_UNWRAP )
Mechanism #34
Mechanism: CKM_GOST28147_CNT (0xD4321825)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #35
Mechanism: CKM_GOST28147_MAC (0x1223)
Key Size: 32-32
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #36
Mechanism: CKM_KUZNYECHIK_KEY_GEN (0xD4321019)
Key Size: 32-32
Flags: 0x8000 ( CKF_GENERATE )
Mechanism #37
Mechanism: CKM_KUZNYECHIK_ECB (0xD432101A)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #38
Mechanism: CKM_KUZNYECHIK_CBC (0xD432101E)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #39
Mechanism: CKM_KUZNYECHIK_CTR (0xD432101B)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #40
Mechanism: CKM_KUZNYECHIK_OFB (0xD432101D)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #41
Mechanism: CKM_KUZNYECHIK_CFB (0xD432101C)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #42
Mechanism: CKM_KUZNYECHIK_OMAC (0xD432101F)
Key Size: 32-32
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #43
Mechanism: CKM_KUZNYECHIK_KEY_WRAP (0xD4321028)
Key Size: 32-32
Flags: 0x60000 ( CKF_WRAP|CKF_UNWRAP )
Mechanism #44
Mechanism: CKM_KUZNYECHIK_ACPKM_CTR (0xD4321042)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #45
Mechanism: 0xD4321043
Key Size: 32-32
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #46
Mechanism: CKM_MAGMA_KEY_GEN (0xD432102A)
Key Size: 32-32
Flags: 0x8000 ( CKF_GENERATE )
Mechanism #47
Mechanism: CKM_MAGMA_ECB (0xD4321018)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #48
Mechanism: CKM_MAGMA_CBC (0xD4321023)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #49
Mechanism: CKM_MAGMA_CTR (0xD4321020)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #50
Mechanism: CKM_MAGMA_OFB (0xD4321022)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #51
Mechanism: CKM_MAGMA_CFB (0xD4321021)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #52
Mechanism: CKM_MAGMA_OMAC (0xD4321024)
Key Size: 32-32
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #53
Mechanism: CKM_MAGMA_KEY_WRAP (0xD4321029)
Key Size: 32-32
Flags: 0x60000 ( CKF_WRAP|CKF_UNWRAP )
Mechanism #54
Mechanism: CKM_MAGMA_ACPKM_CTR (0xD4321040)
Key Size: 32-32
Flags: 0x300 ( CKF_ENCRYPT|CKF_DECRYPT )
Mechanism #55
Mechanism: 0xD4321041
Key Size: 32-32
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #56
Mechanism: CKM_GOSTR3411 (0x1210)
Key Size: 0-0
Flags: 0x400 ( CKF_DIGEST )
Mechanism #57
Mechanism: CKM_GOSTR3411_12_256 (0xD4321012)
Key Size: 0-0
Flags: 0x400 ( CKF_DIGEST )
Mechanism #58
Mechanism: CKM_GOSTR3411_12_512 (0xD4321013)
Key Size: 0-0
Flags: 0x400 ( CKF_DIGEST )
Mechanism #59
Mechanism: CKM_GOSTR3411_HMAC (0x1211)
Key Size: 32-32
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #60
Mechanism: CKM_GOSTR3411_12_256_HMAC (0xD4321014)
Key Size: 32-32
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #61
Mechanism: CKM_GOSTR3411_12_512_HMAC (0xD4321015)
Key Size: 64-64
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #62
Mechanism: CKM_PKCS5_PBKD2 (0x3B0)
Key Size: 32-32
Flags: 0x8000 ( CKF_GENERATE )
Mechanism #63
Mechanism: CKM_PBA_GOSTR3411_WITH_GOSTR3411_HMAC (0xD4321035)
Key Size: 32-32
Flags: 0x8000 ( CKF_GENERATE )
Mechanism #64
Mechanism: CKM_TLS_GOST_KEY_AND_MAC_DERIVE (0xD4321033)
Key Size: 32-32
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #65
Mechanism: CKM_TLS_GOST_PRE_MASTER_KEY_GEN (0xD4321031)
Key Size: 32-32
Flags: 0x8000 ( CKF_GENERATE )
Mechanism #66
Mechanism: CKM_TLS_GOST_MASTER_KEY_DERIVE (0xD4321032)
Key Size: 48-48
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #67
Mechanism: CKM_TLS_GOST_PRF (0xD4321030)
Key Size: 32-32
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #68
Mechanism: CKM_TLS_GOST_PRF_2012_256 (0xD4321016)
Key Size: 32-32
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #69
Mechanism: CKM_TLS_GOST_PRF_2012_512 (0xD4321017)
Key Size: 32-32
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #70
Mechanism: CKM_TLS12_MASTER_KEY_DERIVE (0x3E0)
Key Size: 48-48
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #71
Mechanism: CKM_TLS12_KEY_AND_MAC_DERIVE (0x3E1)
Key Size: 32-32
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #72
Mechanism: CKM_TLS_MAC (0x3E4)
Key Size: 12-48
Flags: 0x2800 ( CKF_SIGN|CKF_VERIFY )
Mechanism #73
Mechanism: CKM_TLS_KDF (0x3E5)
Key Size: 32-48
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #74
Mechanism: CKM_TLS_TREE_GOSTR3411_2012_256 (0xD4321047)
Key Size: 32-32
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #75
Mechanism: CKM_EXTRACT_KEY_FROM_KEY (0x365)
Key Size: 256-512
Flags: 0x80000 ( CKF_DERIVE )
Mechanism #76
Mechanism: CKM_SHA_1 (0x220)
Key Size: 0-0
Flags: 0x400 ( CKF_DIGEST )
Mechanism #77
Mechanism: CKM_MD5 (0x210)
Key Size: 0-0
Flags: 0x400 ( CKF_DIGEST )


> Самое плохое, что может устроить выдавший их УЦ — это внезапно отозвать сертификат.

Если отозвали незаконно, то приступник известен и его надо наказать, а если обоснованно то уберегли владельца от возможных неприятностей
Другая проблема токенов, это подная реализация механизмов в соответствии с PKCS v.2.40, ее в полном объеме тяжело найти на токенах:

См. колонку для Рутокен ЭЦП. Основное всё вроде есть.
Если отозвали незаконно, то приступник известен и его надо наказать, а если обоснованно то уберегли владельца от возможных неприятностей

Именно.
Основное всё вроде есть.

Для работы с электронной подписью все есть.
Над остальным еще предстоит поработать

Многие виды токенов являются только носителями ключей, криптоалгоритмы выполняются основным процессором компьютера, поэтому теоретически можно украсть и ключ с токена. Есть небольшое количество токенов, которые выполняют криптоалгоритмы самостоятельно, и ключи на них могут быть действительно неизвлекаемыми — ключ генерируется внутри токена и никогда его не покидает.
Даже токен в режиме «флешки» лучше пароля т.к. за сертификатом надо дополнительно охотиться, а пароль можно украсть кейлогером. При правильной настройке и использовании токена украсть сертификат невозможно (если верить производителям, но это не точно). А если вместо USB использовать смарткарты и ввод пина на отдельном пинпаде, то и пин не украсть (опять же на правильных устройствах и настройках).
В принципе, почему бы нет? Самое плохое, что может устроить выдавший их УЦ — это внезапно отозвать сертификат.
  • Излишняя юридическая нагрузка с получением и возможной ответственностью при каких-то ситуациях.
  • Вам надо поставить в систему гос. сертификаты и сделать их доверенными. Некоторые критически относятся к таким вещам.
  • Лучше даже не углубляться в практику выдачи сертификатов у нас.
  • Зависимость от третьего лица
  • Сертификат на год
  • Каждый год необходимо заплатить за продление
Флешка-токен это хуже не придумаешь. Извращается сама идея токена. Лучше уж честно делать файл на ФС. Тогда всем все понятно будет. И безопасность такая же.

Сертификаты для внутренних целей через внешние УЦ тоже абсолютное зло. Зачем кому-то знать что тут у нас внутри? Как выдавать сертификаты по клику на все эти сотни контейнеров? А на одноразовые контейнеры как выдавать? Куча вопросов и везде получается что эффективнее самим делать.
И безопасность такая же.

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


Как выдавать сертификаты по клику на все эти сотни контейнеров?

Сертификаты выдаются на УЦ и публикуются. Пользователи, по-хорошему, сами должны ставить на свои токены. На УЦ спокойно выдают сертификаты и на сотни и на тысячи токенов

Будем реалистами. Они подключены примерно всегда. Файл можно использовать на любом числе компьютеров. Даже одновременно.


Пользователь это CI разворачивающая контейнер. Ей бы в апи сходить и получить свой сертификат.

При хранении ключа в ФС компьютера злоумышленник может получить к нему доступ как только получит доступ к компьютеру.

Справедливости ради, даже файловый контейнер может быть зашифрован, тогда надо ещё пароль контейнера знать.
Даже токен в режиме «флешки» лучше пароля т.к. за сертификатом надо дополнительно охотиться, а пароль можно украсть кейлогером.

Конечно лучше. Именно по этому принципу и строятся программно-аппаратные токены LS11USB2016.


При правильной настройке и использовании токена украсть сертификат невозможно

А зачем сертификат крать? Это вещь публичная и доступная всем. Сертификат присутствует в электронной подписи, в подписанном письме и т.д. Получить его нет проблем. Крадут закрытые ключи! А как известно неприступных крепостей не бывает. Вопрос времени. Именно поэтому ограничивают срок действия и самого сертификата и ключей.


Каждый год необходимо заплатить за продление

Если вы сертификат используете в корпоративных целях, то наверняка вы ничего не платите и вам его выдают. Если вы используете в личныз целях с друзьями, то как-то договариваетесь и используете, например, предложенные приложения в статье для выпуска сертификатов в своих нуждах. Но, если вы пользуетесь государственными ресурсами (ФСС, ФНС, ГОСУЛУГИ и т.д. ), то вам придется заплатить за новый сертификат через год. Сертификат это тот же паспорт, а за получение паспорта мы платим.
Кстати, продление сертификата — это плохая идея, ЗАКРЫТЫЙ КЛЮЧ МОЖЕТ БЫТЬ СКОИПРОМЕТИРОВАН. Надежнее и спокойнее получить новый сертификат с новым ключом, как в истории с паспортом с новой фотографией.

Если вы сертификат используете в корпоративных целях, то наверняка вы ничего не платите и вам его выдают. Если вы используете в личныз целях с друзьями, то как-то договариваетесь и используете, например, предложенные приложения в статье для выпуска сертификатов в своих нуждах. Но, если вы пользуетесь государственными ресурсами (ФСС, ФНС, ГОСУЛУГИ и т.д. ), то вам придется заплатить за новый сертификат через год. Сертификат это тот же паспорт, а за получение паспорта мы платим.
Кстати, продление сертификата — это плохая идея, ЗАКРЫТЫЙ КЛЮЧ МОЖЕТ БЫТЬ СКОИПРОМЕТИРОВАН. Надежнее и спокойнее получить новый сертификат с новым ключом, как в истории с паспортом с новой фотографией.
Цель статьи вроде как была настроить безопасный VPN, а не юридически значимый документооборот. Зачем корпоративному VPN именно государственный сертификат не очевидно.

Подавляющее большинство не использует паспорт для прохода через проходную. Работникам выдают удостоверения, карточки, ещё каким-то способом опознают работника. Если для этого постоянно использовать паспорт, то кто-то может не пройти на работу если он у него закончится по сроку, а человек забыл продлить.
Цель статьи вроде как была настроить безопасный VPN

А где в статье написано как строить VPN? В статье речь идет о том как получить сертификат, который мржет использоваться, в частности, в VPN. А все посвящено как создается запрос на сертификат и как по нему выпускается сертификат.


Подавляющее большинство не использует паспорт для прохода через проходную.

Конечно не используют. Они используют пропуск, который получен на основании паспорта.


Зачем корпоративному VPN именно государственный сертификат не очевидно.

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

за сертификатом надо дополнительно охотиться

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

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


Зависит от токена. Есть много токенов (на самом деле, большинство), которые в принципе не умеют самостоятельно выполнять криптоалгоритмы, и для операций, задействующих закрытый ключ, он всегда считывается с токена на компьютер, где в принципе может быть стырен враждебным ПО. Можете посмотреть на сайте КриптоПро, например, какие токены что могут: http://crypto-pro.ru/products/cryptopro-csp

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

Я не говорю, что это приоритетный подход, или что с этого надо начинать. Но если вдруг у пользователей уже есть выданные внешним УЦ сертификаты, то можно их использовать (конечно, если они подходят по алгоритмам, длине ключей, назначению применения и т.д.).
Как вам уже правильно заметили, охотиться надо не за сертификатом, а за закрытым ключом. Сертификат — вещь по определению публичная. Более того, на носителе ключей сертификата может и не быть.
Уже поздно говорить, что под сертификатом имелся в виду закрытый ключ? :)
Зависит от токена. Есть много токенов (на самом деле, большинство), которые в принципе не умеют самостоятельно выполнять криптоалгоритмы, и для операций, задействующих закрытый ключ, он всегда считывается с токена на компьютер, где в принципе может быть стырен враждебным ПО.
Для любых нужд имеет смысл покупать только максимально защищённые токены. И использовать токены тоже надо правильно, не превращая хорошее устройство в флешку.
Я не говорю, что это приоритетный подход, или что с этого надо начинать. Но если вдруг у пользователей уже есть выданные внешним УЦ сертификаты, то можно их использовать (конечно, если они подходят по алгоритмам, длине ключей, назначению применения и т.д.).
IMHO чужими сертификатами имеет смысл пользоваться только если очень сильно надо. Допустим когда удалённый сотрудник неожиданно оказался в карантине, но у него есть государственный ключ, то это, наверно, приемлемо. Если подготовка шла штатно, то ключики лучше выпускать свои.

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

Золотые слова!
Не надо превращать Токены PKCS#11 во флэшки аля CSP-Микросфт с поддержкой российской криптографии.


Уже поздно говорить, что под сертификатом имелся в виду закрытый ключ? :)

Это не тот случай, чтобы было поздно.

Т.е. вся эта простыня свелась к "openssl". И чем это отличается от self-hosted CA с сертификатами для openvpn? Заодно можно и не гост делать, а более стандартное шифрование.

Т.е. вся эта простыня свелась к "openssl"

Можете рассматривать и так, как GUI к части функционала openssl (в части выпуска сертификатов).


Заодно можно и не гост делать, а более стандартное шифрование.

Вообще-то про шифрование здесь никакой речи не идет, даже слово не употреблялось!
Может вы имеете в виду, можно ли создавать сертификаты не только на ГОСТ-ключах? Да, можете попробовать на


RSA

![image]()


И чем это отличается от self-hosted CA

Что это? Сертификаты они и есть сертификаты. С помощью этого приложения вы можете выпускать и сертификаты для VPN.

За Линукс не скажу, а на Windows для генерации CSR есть стандартная утилита certreq.exe. И через PowerShell наверняка можно сделать, возможно, за исключением криптопровайдеров CNG.
на Windows для генерации CSR есть стандартная утилита certreq.exe.

А на Linux есть NSS. Именно для генерации запросов (CSR или PKCS#10). Но как только речь заходит о генерации на базе российской криптографии, то стандартное становится не стандартным. А если говорить о сертификатах то не всегда их можно выпускать на своем компьютере. Ели мы говорим, например. о ГОСУСЛУГах, то надо обращаться в аккредитованный УЦ.

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

Опять же, на Виндах с использованием certreq.exe это сводится к указанию криптопровайдера в .inf-файле описания запроса.

А если говорить о сертификатах то не всегда их можно выпускать на своем компьютере. Ели мы говорим, например. о ГОСУСЛУГах, то надо обращаться в аккредитованный УЦ.

Нет, ну отправка CSR в УЦ и последующее получение и установка сертификатов — это обязательная часть любой нормальной работы с PKI. Этот процесс может быть более или менее удобен и автоматизирован, но избежать его нельзя. Выпуск сертификатов на том же компьютере, где создан запрос — это вырожденный случай для самоподписанных сертификатов.

Не убавить ни прибавить. Спасибо.

Sign up to leave a comment.

Articles

Change theme settings