Certificate based authentication

[Palych]

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

Спасибо.

[АццкоМото]

Палыч, вы неправы!

[Palych]

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

[Slonjra]

в моем понятии, как админа со стороны клиента - в 90% случаев сертификаты это "перебор"..
и я очень рад что пара наших основных заказчиков тоже пришла к этому..
еще пару лет назад у обоих из них была просто невероятно нудная и тупая система идентификации..с сертификатами..
при этом работало только под IE 8 и выше ))) IE 11 вообще не признавало и требовало вернуться к IE 10 и каждый месяц надо было "восстанавливать" сертификат)))
других браузеров вообще не признавал
любой апдейт компа - ронял эту систему
java требовал не выше 6 -25 )))
я очень рад что наконец-то они вернулись к обычной практике user ID / Password.
и это типа монстры - HD и Lowes

[Palych]

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

[katit]

Не использую - но пользуюсь. Тот же APNS чтоб ему пусто быыло. Не могут как люди..

[Teh Instructor]

у нас для тестовых систем своя внутренняя CA - root certificate ставится на все корпоративные машины. Условно говоря, если система тестовая по адресу "system.staging.company.com" то для нее сертификат выдается внутренней CA. А для продакшен системы "system.company.com" покупается Verisign.

[Palych]

у нас для тестовых систем своя внутренняя CA - root certificate ставится на все корпоративные машины.

На клиенты или на сервера?

Условно говоря, если система тестовая по адресу "system.staging.company.com" то для нее сертификат выдается внутренней CA. А для продакшен системы "system.company.com" покупается Verisign.

Уточню - речь идет о сертификатах чтобы HTTPS работал?
Или сертификатах, которые вместо логина/пароля?

[Teh Instructor]

у нас для тестовых систем своя внутренняя CA - root certificate ставится на все корпоративные машины.

На клиенты или на сервера?

Условно говоря, если система тестовая по адресу "system.staging.company.com" то для нее сертификат выдается внутренней CA. А для продакшен системы "system.company.com" покупается Verisign.

Уточню - речь идет о сертификатах чтобы HTTPS работал?
Или сертификатах, которые вместо логина/пароля?

ROOT сертификат ставится везде - сервера они же тоже ходят к сервисам на других серверах по HTTPS.
И да, речь о сертификатах только для HTTPS. Те которые для вместо логина/пароля не используем.

[АццкоМото]

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

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

[Palych]

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

С точки зрения клиента - все замечательно: удобно.
Со стороны сервера (разработчиков серверных приложений/сервисов) по моим наблюдениям часто встречаются два основных видов заблуждений:
- Считают что клиент и сервер должны обменяться сертификатами, по аналогии с паролями: сервер знает "хешированные пароли" пользователей (public keys), клиенты соответственно хранят как зеницу ока свои настоящие пароли (private keys). Сервер типа запрашивает пароль, клиент отвечает...
- Считают что приложению/сервису не нужно ничего знать про эти секьюрные дела: пишем только фунцкионал, а потов в конфигурации прикрутим keystores - и готово, принимай, Родина трудовой подарок!

(извиняюсь, пошел бить мешок. допишу завтра)

[mavr]

Со стороны сервера (разработчиков серверных приложений/сервисов) по моим наблюдениям часто встречаются два основных видов заблуждений:
- Считают что клиент и сервер должны обменяться сертификатами, по аналогии с паролями: сервер знает "хешированные пароли" пользователей (public keys), клиенты соответственно хранят как зеницу ока свои настоящие пароли (private keys). Сервер типа запрашивает пароль, клиент отвечает...
- Считают что приложению/сервису не нужно ничего знать про эти секьюрные дела: пишем только фунцкионал, а потов в конфигурации прикрутим keystores - и готово, принимай, Родина трудовой подарок!

(извиняюсь, пошел бить мешок. допишу завтра)

У нас используется.
Функционал логин/пароль тоже есть но по умолчанию предлагается использовать сертификат.

А эти два заблуждения как вы описали разве не разные шаги одного процесса?

[Palych]

А эти два заблуждения как вы описали разве не разные шаги одного процесса?

Может быть так оно и есть...
Когда используются самопальные сертификаты - действительно некая авторизация получается сама собой: доступ имеют только те, у кого есть свой сертификат. Сервис "защищен паролем"...
Первая засада получается в том, что когда сервер шлёт Certificate Request - он вываливает полный список пользователей о которых ему известно: "который из этих подходит?"
Собственно правильный ответ на первое заблуждение: сервер перечисляет не сами сертификаты, а тех, кто их выдал: "Есть ли у Вас сертификат, выданный одной из этих контор?"
Стало быть хранить нужно ключ(и) CAs, а не клиентов.
Осознав ошибку, раскаявшись и раздрав одежды, исправляемся: заставляем всех клиентов купить сертификаты у Verisign, выкидываем из keystore все, кроме цепочки их ключей. Теперь certiicate request содержит только одну строку: "есть ли у Вас ключ, подписанный Verisign?"
Вздыхаем с облегчением: мы успешно зааутсёрсили управление сертификатами, умыли руки, почиваем на лаврах.
... До тех пор, пока не осознаем последствия второго заблуждения: теперь каждая кухарка имеющая верисайновский сертификат имеет полный доступ к нашему сервису!

[АццкоМото]

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

С точки зрения клиента - все замечательно: удобно.)

Так в чем засада-то?

Со стороны сервера (разработчиков серверных приложений/сервисов) по моим наблюдениям часто встречаются два основных видов заблуждений:
- Считают что клиент и сервер должны обменяться сертификатами, по аналогии с паролями: сервер знает "хешированные пароли" пользователей (public keys), клиенты соответственно хранят как зеницу ока свои настоящие пароли (private keys). Сервер типа запрашивает пароль, клиент отвечает...)

Это вроде очевидная глупость - трудно поверить, что массы трудящихся реально впадают в этот маразм-

- Считают что приложению/сервису не нужно ничего знать про эти секьюрные дела: пишем только фунцкионал, а потов в конфигурации прикрутим keystores - и готово, принимай, Родина трудовой подарок!

А тут-то что не так?

[АццкоМото]

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

о, да вы бредите

[mavr]

А эти два заблуждения как вы описали разве не разные шаги одного процесса?

Может быть так оно и есть...
Когда используются самопальные сертификаты - действительно некая авторизация получается сама собой: доступ имеют только те, у кого есть свой сертификат. Сервис "защищен паролем"...
Первая засада получается в том, что когда сервер шлёт Certificate Request - он вываливает полный список пользователей о которых ему известно: "который из этих подходит?"
Собственно правильный ответ на первое заблуждение: сервер перечисляет не сами сертификаты, а тех, кто их выдал: "Есть ли у Вас сертификат, выданный одной из этих контор?"
Стало быть хранить нужно ключ(и) CAs, а не клиентов.
Осознав ошибку, раскаявшись и раздрав одежды, исправляемся: заставляем всех клиентов купить сертификаты у Verisign, выкидываем из keystore все, кроме цепочки их ключей. Теперь certiicate request содержит только одну строку: "есть ли у Вас ключ, подписанный Verisign?"
Вздыхаем с облегчением: мы успешно зааутсёрсили управление сертификатами, умыли руки, почиваем на лаврах.
... До тех пор, пока не осознаем последствия второго заблуждения: теперь каждая кухарка имеющая верисайновский сертификат имеет полный доступ к нашему сервису!

Вы ничего не попутали?
Подпись CA означает что сертификат кошерный а не то что мы ему доверяем.
Список разных CA в key store это всего лишь список тех чьей подписи мы верим.
А доверяем мы конкретному сертификату или нет уже следующий шаг. Не?

[Palych]

- Считают что приложению/сервису не нужно ничего знать про эти секьюрные дела: пишем только фунцкионал, а потов в конфигурации прикрутим keystores - и готово, принимай, Родина трудовой подарок!

А тут-то что не так?

Не так:

Подпись CA означает что сертификат кошерный а не то что мы ему доверяем.
Список разных CA в key store это всего лишь список тех чьей подписи мы верим.
А доверяем мы конкретному сертификату или нет уже следующий шаг.

Вот этот-то шаг и пропускается.
В случае с 3rd party CA аутентификация становится настолько независимой от сервера/владельца сервиса, что ей уже невозможно подменить авторизацию.

[mavr]

- Считают что приложению/сервису не нужно ничего знать про эти секьюрные дела: пишем только фунцкионал, а потов в конфигурации прикрутим keystores - и готово, принимай, Родина трудовой подарок!

А тут-то что не так?

Не так:

Подпись CA означает что сертификат кошерный а не то что мы ему доверяем.
Список разных CA в key store это всего лишь список тех чьей подписи мы верим.
А доверяем мы конкретному сертификату или нет уже следующий шаг.

Вот этот-то шаг и пропускается.
В случае с 3rd party CA аутентификация становится настолько независимой от сервера/владельца сервиса, что ей уже невозможно подменить авторизацию.

Я вот этой комбинации слов никогда не слышал.

[Palych]

В случае с 3rd party CA аутентификация становится ...

Я вот этой комбинации слов никогда не слышал.

А если так:
В случае использования сертификатов от сторонних Certificate Authorities, аутентификация становится...
Понятнее?

[mavr]

В случае с 3rd party CA аутентификация становится ...

Я вот этой комбинации слов никогда не слышал.

А если так:
В случае использования сертификатов от сторонних Certificate Authorities, аутентификация становится...
Понятнее?

Технически self signed совершенно ничем не отличается от подписанного третьей стороной.
Разница только в том что ключ для проверки кошерности сертификата от коммерческого CA в key store уже есть и ему принято доверять.
А root ключ от самосгенеренного CA нужно добавлять ручками.

Потому я все еще не догоняю проблемы.

[erix]

А доверяем мы конкретному сертификату или нет уже следующий шаг. Не?

Сертификату per se мы доверяем по любому, если он подписан trusted CA и не присутствует в CRL.
"Следующий шаг" будет - доверяем ли конкретному CN (Common Name), имплементируется на стороне сервиса и к CA никакого отношения не имеет.

Многие плавают в терминологии и, зачастую, как демонстрирует этот топик, и в основах PKI, по-этому с сертификатами обычно получается communication breakdown and urban legends live on.

А вообще, mavr дело говорит.

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

Концептуально, аутентификация по сертификату может быть рассмотрена по аналогии с аутентификацией по IP-адресу: когда достаточно, а когда нет...

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

Спасибо.

You are welcome

[erix]

у нас для тестовых систем своя внутренняя CA - root certificate ставится на все корпоративные машины. Условно говоря, если система тестовая по адресу "system.staging.company.com" то для нее сертификат выдается внутренней CA. А для продакшен системы "system.company.com" покупается Verisign.

Дык надо было за два пункта проголосовать

[erix]

Уточню - речь идет о сертификатах чтобы HTTPS работал?
Или сертификатах, которые вместо логина/пароля?

Palych, here you go, правильное название топика: Certificate based authentication Certificate based CLIENT authentication
Так как зеленая строка в browser-е означает что сервер прошел аутентификацию на вашем клиенте. In other words: authentication can be and often is mutual.

Каша у вас в голове и люди вас понять не имеют возможности

[Palych]

А доверяем мы конкретному сертификату или нет уже следующий шаг. Не?

Сертификату per se мы доверяем по любому, если он подписан trusted CA и не присутствует в CRL.
"Следующий шаг" будет - доверяем ли конкретному CN (Common Name), имплементируется на стороне сервиса и к CA никакого отношения не имеет.

Многие плавают в терминологии и, зачастую, как демонстрирует этот топик, и в основах PKI, по-этому с сертификатами обычно получается communication breakdown and urban legends live on.

Вообще-то я об этом и затеял разговор: про то как communication breakdown and urban legends не просто ломают приложения, а создают дырки в безопасности.

А вообще, mavr дело говорит.

Сертификаты не имеют прямого отношения к авторизации, более того, они не обязаны полностью замещать собой аутентификацию:

С этим я не спорю.

добавить hash пароля на стороне сервиса к конкретному CN и запросить его (пароль) у клиента никто не запрещает.

А вот это, извиняюсь, как раз пример подмены авторизации аутентификацией.
Или, выражаясь академическим языком - наматывание изоленты на презерватив.

[Palych]

добавить hash пароля на стороне сервиса к конкретному CN и запросить его (пароль) у клиента никто не запрещает.

А вот это, извиняюсь, как раз пример подмены авторизации аутентификацией.
Или, выражаясь академическим языком - наматывание изоленты на презерватив.

Уточню: пароль - средство аутентификации, он защищает Identity, а не доступ.
Авторизация в случае с Certificate based client authentication (спасибо за уточнение) CN нужно использовать для определения что клиенту можно, а что нельзя.
А проверять CN ещё раз паролем, или/и IP адресом - добавляет больше геморроя, чем безопасности.