Как разрешить только один вход по одному сертификату?

Question

[Sergey]

Ситуация такая.
Есть сервер на Nginx. Есть самоподписанные сертификаты.
Есть такой блок конфигурации сервера:

listen       443;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl on;
ssl_verify_client on;
ssl_certificate        /etc/nginx/ssl/server-bundle.crt;
ssl_certificate_key    /etc/nginx/ssl/server.nopass.key;
ssl_client_certificate /etc/nginx/ssl/ca.crt;
ssl_crl                /etc/nginx/ssl/ca.crl;

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

Comments

[Sergey]

Да, забыл пояснить, именно интересует реализация средствами nginx.

[Сергей Савостин]

Что в Вашем понимании "сессия" нужно для начала уяснить

[Sergey]

Сергей Савостин: "Суть проблемы в том, что хотим жестко ограничить: 1 сертификат = 1 вход."

[Сергей Савостин]

Sergey: "вход" куда?

[Сергей]

Сергей Савостин: если туго. то в .... =)

[Sergey]

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

[Сергей]

Sergey: не не не. ваш русский норм. но вы пишите им чудные вещи). то есть нормальный человек скажет "я хочу секса". а вы пишете "я желаю, то чего природа сделала для пары, чтоб было приятно и в то же время не опасно 0_о

[Сергей Савостин]

Sergey: nginx не контролирует "вход", он проверяет валидность сертификата и устанавливает $ssl_client_verify Что делать с этой переменной дальше - пускать, не пускать, проверять что-то еще - дело приложения.

[Sergey]

Ясно, то есть nginx'ом никак, собственно вопрос так и был задан. "возможно ли такое вообще?"

[Сергей Савостин]

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

[Sergey]

Хорошо, логично.
Тогда так сформулируем, nginx проводит валидацию сертификата, одновременно получает client_id, с помощью stream модуля мы можем видеть сколько его сессия (скажем какая-то продолжительность жизни клиента на сокете) существует. Собственно , можно ли самим nginx ограничить только одну сессию для одного сертификата?

[Sergey]

client_id = client_serial

[Сергей Савостин]

Sergey: Как Вы хотите идентифицировать (различать) пользователей с одним сертификатом? По ip? Cookies?

[Sergey]

По куки, так как куча клиентов с 1го ip

[Sergey]

то есть ситуация, что много вкладок -не пугает

[Сергей Савостин]

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

[Алексей Ямщиков]

Сергей Савостин: Думаю речь идёт не о SSL сертификате для домена.
Sergey: я правильно понимаю, что вы выдали клиенту именной сертификат, которым он должен авторизоваться на сайте. И разговор не про сертификат для https соединение?

[Алексей Ямщиков]

Sergey: blog.nategood.com/client-side-certificate-authenti...

[Sergey]

Алексей Ямщиков: Все верно

[Sergey]

Сергей Савостин: Мы априори считаем, что один сертификат не может быть у нескольких пользователей

[Сергей Савостин]

Sergey: не понял, тогда зачем этот вопрос? Не может быть второго входа ;) Возвращаемся к вопросу что такое "вход" в Вашем приложении...

[Сергей Савостин]

Алексей Ямщиков: я понимаю, что разговор о клиентских сертификатах

[Сергей Савостин]

Sergey: ок, cookie. Т.е. нужно где-то хранить связь cookie и client_serial. Думаю Вы уже где-то храните это. Собственно, при "входе", там где Ваше приложение ставит эту cookie, проверяйте нет ли кого-то с таким же client_serial (ну там с таймаутом и пр.) Или нужно пустить нового и "выкинуть" всех старых?

[Алексей Ямщиков]

Sergey: я думаю вам не обойтись без доп обвязки. Какое нибудь хранилище где будет лежать связка user:ip:sessiontoken и скрипт (lua &?) который при авторизации пользователя проверяет его авторизованность и ip

[Sergey]

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

[Sergey]

То что Вы говорите, господа, уже есть. Как и в начале повторюсь - хотелось сделать средствами nginx. Но судя по вопросам уже понял, что таковой возможности нет.

[Sergey]

Или, точнее по ответам)

[Сергей Савостин]

Sergey: ну, определять человека за компьютером еще не научились, разве что по отпечаткам. Поэтому под "другим человеком" подразумевается "другой компьютер" или даже точнее "другой браузер".

[Sergey]

Честно полагал, что nginx может считать связку ip+cookie+session и ее принимать за уникального клиента

[Сергей Савостин]

Sergey: session - понятие приложения (что у Вас там php или node.js, и как оно с этими сессиями работает, nginx не знает). Ну, а ip + cookie пожалуйста.

Answer 1

[Сергей Савостин]

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

Приложение при "входе", т.е. там, где ставит cookie скажем с именем SESSION_KEY, создает папку (можно на ram диске, чтоб быстрее) с именем $client_serial (если нет такой) и в ней файл с именем $session_key. И удаляет все другие файлы в этой папке.
В Nginx:

if ($ssl_client_verify = "VERIFIED") {
   if(-f /ramdisk/sessions/$ssl_client_serial/) {
      if(!-f /ramdisk/sessions/$ssl_client_serial/$cookie_SESSION_KEY/) {
         return 403;
      }
   }
}

Ну там проверить не пришла ли бяка в $cookie_SESSION_KEY и пр.
P.S. Только в качестве идеи.

Comments

[Sergey]

Браво, спасибо, дальше сами копать будем. Единственный затык - действительно удалять тех, кто вышел

[Сергей Савостин]

Sergey: и вышел, и по таймауту. Т.е. срипт на крон. Большой костыль...

[Sergey]

Мм. А если все-таки использовать session с upstream?

[Сергей Савостин]

Sergey: Вы про то ,что проверять файл сессии из php? а где привязка его к $ssl_client_serial? Можно попробовать включить $ssl_client_serial в имя файла сессии.

[Sergey]

Нет-Нет. На самом деле есть модули транслируют в nginx переменные из php. Но не это интересует. В модуле upstream есть такое понятие (в момент записи в лог) как session. Вот на него привязаться нельзя?

[Сергей Савостин]

Sergey: если честно, не нашел такого в документации. Имхо там еще одна cookie, т.е. можно.

Answer 2

[ТыжСисАдмин]

Не совсем уверен в том чего вы желаете получить на выходе, но могу предположить и предложить ознакомится с данной ссылкой habrahabr.ru/post/213741

Comments

[Sergey]

Нет, это совсем не то. У нас уже все работает нормально на самоподписанных сертификатах с центром отзыва и т.д. Суть проблемы в том, что хотим жестко ограничить: 1 сертификат = 1 вход.

[Сергей]

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

[Сергей]

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

[Sergey]

Там проверяется серверным языком дополнительно - та ли связка пользователь-ИП-сертификат итд

[Сергей]

серверным языком? 0_о

[Sergey]

Ну да, nginx транслирует сертификатные данные на perl, java, php и там легко проверить, тот ли клиент вошел с этим сертификатом. Но разве разговор сейчас об этом?

[Сергей]

Sergey: эмм. вы вообще понимаете что такое сертификат? открытая часть ключа. закрытая???

[Sergey]

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

[Сергей]

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

[Сергей]

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

[Сергей]

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

[ТыжСисАдмин]

Сергеи, заспамили все уведомления :)