Certificate based authentication

[АццкоМото]

вот я когда коннектюсь к google cloud engine - я рушу представления Палыча об аутентификации и авторизации

[erix]

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

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

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

Не хотите - не проверяйте - хозяин - барин, я не понимаю с чем вы спорите. Как бы multi-factor аутентификация существует; когда-то в ней есть необходимость, когда-то нет. Я понимаю, что у господ программистов обычно кроме веб2.99 на ум ничего не приходит, но, например, в случае client VPN успешно используется аутентификация на основании как выданного компьютеру сертификата InternalCA так и RSA passcode. С вашей точки зрения это презерватив с изолентой, но есть и другая точка зрения, разделяемая достаточно большим количеством профессионалов.

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

[erix]

вот я когда коннектюсь к google cloud engine - я рушу представления Палыча об аутентификации и авторизации

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

[Palych]

Не хотите - не проверяйте - хозяин - барин, я не понимаю с чем вы спорите.

Честно говоря - я невнимательно прочитал следующую фразу. Точнее - выделенное слово.

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

Был не прав, приношу извинения.

[Sergunka]

Я помнится даже специально написал пример и загитхабил для Томкета как shake hands происходит между сервером и клиентом. Как оказалось через год это один из самых читаемых топиков у меня в блоге. С десяток перцев со всего мира приходит - тянутся черти к знаниям

https://vyatkins.wordpress.com/2013/11/ ... fications/


Особо ржачно получился баш файл который генерит сертификаты и трасты к ним как для клиента так и для сервака

https://github.com/SVyatkin/tomcat-ssl- ... SSCerts.sh

[Palych]

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

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

Разница количественная, а количество переходит в качество.

Представим пограничную службу государства Бурухтания. Паспортный контроль.
Согласно законодательству Бурухтании право на въезд в страну обладают:
- Граждане Бурухтании
- Граждане США
- Граждане Намибии

Соответственно паспорта выданные этими странами дают право на въезд.
Естественно список этих стран - публичная информация. Его можно найти на сайте правительства Бурухтании, на бумажке у окошка паспортиски, на бурухтано-язычных форумах и проч.
По этой аналогии сервер, использующий Certificate based client authentication при каждой попытке к нему присоединится выдаёт

Code: Select all

*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US>
...

Так клиенты знают какой паспорт(private key) нужно достать из широких штанин (keystore)

Теперь представим что границу пытается перейти Эдвард Сноуден.
Его паспорт можно рассматривать под лупой, сверять фотографию, отпечатки пальцев, ДНК - всё равно это будет действительный паспорт, выданный правительством США.
Тем не менее, согласно более позднему решению того же правительства, этот паспорт уже не даёт ему право пересекать границу Бурухтании.
А пропустить его - значит обречь страну на смерть и разрушения...

И решили бурухтанцы - не будем полагаться на иностранные правительства в решении кому въезжать, а кому нет.
И перешли на индивидуальные визы.
(Тут следует заметить что правит Бурухтанией король Бурухтан Второй Второй, сын Бурухтана Второго)
Сделали они это так: те кому нужно въехать в страну предоставляют о себе данные, и если всё нормально - их заносят в список.
А в качестве списка они использовали список стран: теперь в нём вместо стран - те, кто подал заявку на визу и получил разрешение.
Если это приложить к subj. - получится что сервер будет выдавать:

Code: Select all

*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<CN=Vasil Poopkin, OU="accounting dept", O="Horns & Hooves, Inc.", C=RU>
<CN=BurukhtanSecondSecond, OU="king", O="Burukhtan Government", C=BRKH>
...

И если в сервер работает с миллионом пользователей, и у каждого свой self signed certificate - список будет содержать миллион записей и поле Issuer (которое совпадает с Owner в данном случае) будет доступо всем желающим.

[mavr]

Представим пограничную службу государства Бурухтания. Паспортный контроль.
Согласно законодательству Бурухтании право на въезд в страну обладают:
- Граждане Бурухтании
- Граждане США
- Граждане Намибии

В аналогии упущен один шаг.
Подпись от CA позволяет проверить что это действительно тот самый сертификат, а не подделаный дядей Мухаммедом (проверка подлинности паспорта и сверяние фотографии с мордой лица)

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

И если в сервер работает с миллионом пользователей, и у каждого свой self signed certificate - список будет содержать миллион записей и поле Issuer (которое совпадает с Owner в данном случае) будет доступо всем желающим.

Разумеется.
Так же как и при доступе по паролю храним миллион записей с паролями и логинами.
А ожидалось чего то другого?
В этом плане никакого облегчения нет и не обещалось.

[Palych]

И если в сервер работает с миллионом пользователей, и у каждого свой self signed certificate - список будет содержать миллион записей и поле Issuer (которое совпадает с Owner в данном случае) будет доступо всем желающим.

Разумеется.
Так же как и при доступе по паролю храним миллион записей с паролями и логинами.
А ожидалось чего то другого?
В этом плане никакого облегчения нет и не обещалось.

Когда мы логинимся куда-то - мы не видим список всех пользователей системы.

[erix]

И если в сервер работает с миллионом пользователей, и у каждого свой self signed certificate - список будет содержать миллион записей и поле Issuer (которое совпадает с Owner в данном случае) будет доступо всем желающим.

Пытаюсь вкурить эту фразу... Не вкуривается. Что будет доступно всем желающим? Имена, кому были выданы визы? Почему?

[Palych]

И если в сервер работает с миллионом пользователей, и у каждого свой self signed certificate - список будет содержать миллион записей и поле Issuer (которое совпадает с Owner в данном случае) будет доступо всем желающим.

Пытаюсь вкурить эту фразу... Не вкуривается. Что будет доступно всем желающим? Имена, кому были выданы визы? Почему?

При обмене рукопожатиями сервер сообщает клиенту с какими сертификатами он работает.
Другими словами - перечисляет "Issuer" field всех сертификатов в trust store. (Если клиент на java - запустите его с -Djavax.net.debug=ssl и проищите в получившемся потоке "*** CertificateRequest")

Если все клиенты используют self signed certs:
- сертификат каждого клиента будет в trust store сервера
- соответственно все они будут выдаваться клиентам в процессе рукопожатия.

P.S. я кажется перепутал: key store, не trust store... Но суть не в этом.

[erix]

Чего-то я сомневаюсь что сервер обязан слать клиенту весь список acceptable CAs, prooflink в лице RFC и/или SSL decoded TCPdump session приветствуются. Java как таковая к вопросу перпендикулярна.

Чисто educated guess: а вы уверены, что -Djavax.net.debug=ssl показывает именно что сервер выдает этот список, а не клиент parses its store?

Show me the step:
http://docs.oracle.com/javase/7/docs/te ... Debug.html

[Palych]

Чего-то я сомневаюсь что сервер обязан слать клиенту весь список acceptable CAs, prooflink в лице RFC и/или SSL decoded TCPdump session приветствуются. Java как таковая к вопросу перпендикулярна.

Я привёл выше decoded SSL traffic snapshot.
Он сделан с помошью Java, другого под рукой нету.
Да и какая разница чем он сделан, если он показывает ключи сервера, на клиенте этой информации нет по определению.

[Palych]

Show me the step:
http://docs.oracle.com/javase/7/docs/te ... Debug.html

Это из другой оперы:

java -Djavax.net.debug=all \
-Djavax.net.ssl.trustStore=trustStore
SSLSocketClientWithClientAuth bongos 2001 /index.html

Там вообще нет client authentication.

[erix]

Похоже, что лист необязателен:

Code: Select all

A second solution is to configure Schannel to no longer send the list of trusted root certification authorities during the TLS/SSL handshake process.  This can be done by adding this registry entry on the web server
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Value name: SendTrustedIssuerList 
Value type: REG_DWORD 
Value data: 0 (False)

http://www.codit.eu/blog/2013/04/03/tro ... ue-on-iis/

[erix]

Show me the step:
http://docs.oracle.com/javase/7/docs/te ... Debug.html

Это из другой оперы:

java -Djavax.net.debug=all \
-Djavax.net.ssl.trustStore=trustStore
SSLSocketClientWithClientAuth bongos 2001 /index.html

Там вообще нет client authentication.

Если вы задаете вопросы на форуме, потрудитесь хотя бы внимательно читать ответы на ваши вопросы. А то выглядит мягко говоря непрофессионально. У вас уже это случается второй раз в этом топике:

Code: Select all

In this example, we connect using the SSLSocketClientWithClientAuth sample application to a simple HTTPS server that requires client authentication, then send a HTTPS request and receive the reply.

[Palych]

Если вы задаете вопросы на форуме, потрудитесь хотя бы внимательно читать ответы на ваши вопросы. А то выглядит мягко говоря непрофессионально. У вас уже это случается второй раз в этом топике:

Code: Select all

In this example, we connect using the SSLSocketClientWithClientAuth sample application to a simple HTTPS server that requires client authentication, then send a HTTPS request and receive the reply.

Ещё раз извиняюсь, не всегда получается вчитываться, отвлекают... Я понимаю что это не извиняет меня, просто пытаюсь объяснить.

И всё-таки в данном примере мне непонятны два момента:
1. отсутствие keystore (not truststore) у клиента. Где клиент возмёт private keys?
2. Почему handshake начинается с
***
found key for : duke

Кто такой duke? Папа ихний duke?
Это не соответствует тому что я вижу

Опять же - где этот duke was found?...

[Palych]

Похоже, что лист необязателен:

Я так понимаю - он необязателен если не используется client authentication:
http://www-01.ibm.com/support/knowledge ... tm?lang=en

If the server requires a digital certificate for client authentication, the server sends a "client certificate request" that includes a list of the types of certificates supported and the Distinguished Names of acceptable Certification Authorities (CAs).

Вот здесь более откровенно написано:
http://www.slashroot.in/understanding-s ... e-protocol

Client Certificate request: This is seldom used, because this is only used, when the client also needs to get authenticated, by a client certificate.

Собственно это я и хотел выяснить добавляя опрос к топику.

[mavr]

При обмене рукопожатиями сервер сообщает клиенту с какими сертификатами он работает.
Другими словами - перечисляет "Issuer" field всех сертификатов в trust store. (Если клиент на java - запустите его с -Djavax.net.debug=ssl и проищите в получившемся потоке "*** CertificateRequest")

И что в этом ужасного?
Это же public key. Все ключи от коммерческих CA уже и так должны быть у клиентов.

Если все клиенты используют self signed certs:
- сертификат каждого клиента будет в trust store сервера
- соответственно все они будут выдаваться клиентам в процессе рукопожатия.

Да нет никакой разницы self signed или коммерческий CA. Абсолютно.

Third party CA - кто то имеет CA, предлагает услугу подписи сертификатов и прилагает усилия распространения CA public key как можно большему числу пользователей.
Self signed - вы сами установили и настроили собственный CA сервер и подписываете сертификаты сами, соответственно забота распространения CA public key на вас.

Если вы говорите о случае когда КАЖДЫЙ клиент использует сертификат подписанный им самим и таких клиентов много, то это весьма странный случай. Скорее всего использование CA signed сертификатов для этого не подходит.
Например ssh сертификаты не требуют CA подписи, достаточно просто добавить public key клиента в access list.

[Palych]

Похоже, что лист необязателен:

Code: Select all

A second solution is to configure Schannel to no longer send the list of trusted root certification authorities during the TLS/SSL handshake process.  This can be done by adding this registry entry on the web server
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Value name: SendTrustedIssuerList 
Value type: REG_DWORD 
Value data: 0 (False)

http://www.codit.eu/blog/2013/04/03/tro ... ue-on-iis/

Действительно: https://tools.ietf.org/html/rfc5246#section-7.4.4

A non-anonymous server can optionally request a certificate from the client,

Спасибо за просветительскую деятельность!

[Palych]

Если вы говорите о случае когда КАЖДЫЙ клиент использует сертификат подписанный им самим и таких клиентов много, то это весьма странный случай. Скорее всего использование CA signed сертификатов для этого не подходит.
Например ssh сертификаты не требуют CA подписи, достаточно просто добавить public key клиента в access list.

Именно об этом случае я и говорю.
Именно этим случаем я лично сталкиваюсь регулярно.
Честно говоря, только один раз видел собственное CA - в нашей конторе. И те быстро от него отказались в пользу Verisign.

[mavr]

Если вы говорите о случае когда КАЖДЫЙ клиент использует сертификат подписанный им самим и таких клиентов много, то это весьма странный случай. Скорее всего использование CA signed сертификатов для этого не подходит.
Например ssh сертификаты не требуют CA подписи, достаточно просто добавить public key клиента в access list.

Именно об этом случае я и говорю.
Именно этим случаем я лично сталкиваюсь регулярно.
Честно говоря, только один раз видел собственное CA - в нашей конторе. И те быстро от него отказались в пользу Verisign.

А нахрена собственно?
CA по сути только привязывает сертификат к common name.
Понятно зачем это делать для сервера. Но зачем это делать для клиента?
Ведь сам сертификат уже добавлен руками в разрешенный список. Какой смысл после этого проверять при входе на какой CN он выдан?

[Palych]

Понятно зачем это делать для сервера. Но зачем это делать для клиента?
Ведь сам сертификат уже добавлен руками в разрешенный список. Какой смысл после этого проверять при входе на какой CN он выдан?

Я не увеоен правильно понимаю...
Вы считаете что для client authentication правильным будет использовать "not signed" сертификаты, как в ssh, класть публичные ключи на сервер, приватные - у клиента, и всё?

[mavr]

Понятно зачем это делать для сервера. Но зачем это делать для клиента?
Ведь сам сертификат уже добавлен руками в разрешенный список. Какой смысл после этого проверять при входе на какой CN он выдан?

Я не увеоен правильно понимаю...
Вы считаете что для client authentication правильным будет использовать "not signed" сертификаты, как в ssh, класть публичные ключи на сервер, приватные - у клиента, и всё?

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

[Palych]

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

И так:
- Подписываем сертификаты у одной или максимум немногих CA (свои, сторонние - mavr прав, это не важно).
- Кладем публичные ключи в trust store
- Чтобы обеспечить остаток AAA (Authorization and Accounting) в приложении используем информацию из сертификата: CN, OU, O, etc. сверяя ее с базой.

Кто-нибудь видел чтобы так делали?
Может тут засада какая-то, которой я не вижу?

[Palych]

Например ssh сертификаты не требуют CA подписи, достаточно просто добавить public key клиента в access list.

Прежде чем тема уйдет в архив, хотел бы подметить принципиальное различие между SSH и TLS.
Различие это в порядке обмена информацией при рукопожатии.

В SSH клиент вначале шлет имя пользователя.
Потом уже договариваются как это имя подтверждать: паролем, сертификатом...
Таким образом сервер может выбрать публичные ключи, которые связаны с конкретным пользователем.
И сертификат (private key) работает исключительно как пароль.

В случае TLS обмен ключами идет до того как пользователь себя назвал. Потому как TLS по задумке protocol agnostic.
Таким образом сервер должен сравнить private key пользователя со всеми известными публичными ключами всех потенциальных пользователей. Для этого сервер и вываливает список тех, кому он доверяет (хотя как мы выяснили - это не обязательно)
И только после сравнения станет известно кто именно достучался до сервера.
То есть - сертификат в TLS работает как имя пользователя и пароль в одном флаконе.