Компьютерный форум
Правила
Вернуться   Компьютерный форум > Форум программистов > Теория программирования > Общие вопросы создания ПО
Перезагрузить страницу Аутентификация по SSL
Ответ
 
Опции темы Опции просмотра
  (#1 (permalink)) Старый
alastor alastor вне форума
Member
 
Сообщений: 13
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 16.08.2008
По умолчанию 16.01.2010, 09:35

Народ, подскажите пожалуйста, какое ПО можно написать для защиты дипломной на тему "Аутентификация в беспроводных сетях стандарта 802.16 по протоколу SSL", до этого была другая тема, "PKI и УЦ", по вине лаборантов, утвердили не ту. я в шоке, мыслей полный 0. Подскажите пожалуйста.
Ответить с цитированием
  (#2 (permalink)) Старый
Влад Влад вне форума
Специалист
 
Сообщений: 3,884
Сказал(а) спасибо: 1
Поблагодарили 25 раз(а) в 25 сообщениях
Регистрация: 27.06.2002
Адрес: Санкт-Петербург
По умолчанию 17.01.2010, 13:09

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


The difference between theory and practice is that in theory, there is no difference between theory and practice, but in practice, there is.
Ответить с цитированием
  (#3 (permalink)) Старый
Samsonov Samsonov вне форума
Member
 
Сообщений: 13
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 28.04.2010
По умолчанию 11.06.2010, 09:35

Вопрос под тем же заголовком, но по другой теме.

Представим себе веб-приложение, использующее SSL не только для шифрования канала, но и для 2-сторонней аутентификации. То есть не только клиент проверяет подлинность сервера, но и сервер имеет возможность идентифицировать и аутентифицировать клиентов по их сертификату. Таким образом, клиентам либо совсем не нужны пароли для доступа к приложению, либо достаточно каких-нибудь коротких PIN-кодов.

Теперь представим себе, что веб-интерфейс — это всего лишь «тонкий» посредник между пользователем и реальным приложением. То есть веб-сервер, конечно, как-то аутентифицирует себя при связи с прикладным сервером, но только ради возможности вести диалог. Основная авторизация базируется на реквизитах пользователя, которые веб-сервер передаёт приложению. Другими словами, веб-сервер здесь — просто агент, никоим образом не доверенный: помимо основного агента, обращаться к приложению могут и сторонние агенты, создаваемые и управляемые третьими лицами.

Вопрос: возможно ли во втором случае сохранить простоту аутентификации первого варианта? Ведь то обстоятельство, что агент успешно проверил подлинность клиента по SSL-сертификату, совершенно никак не отражается на диалоге агента с приложением. Особая ирония в том, что как раз агенту-то вообще наплевать на аутентичность пользователя, но только агент и имеет доступ к этой информации.

Пока вижу только один способ — попросить клиента подписать какую-нибудь строку текста, сгенерированную приложением. Но это не только добавляет лишний шаг к процедуре входа на сайт. Для этого клиенту сначала надо установить какой-нибудь CAPICOM SDK, а потом ещё каждый раз получать предупреждения, что сайт запрашивает доступ к хранилищу сертификатов; да и работать это будет, наверное, только в Internet Explorer.

Может, существуют какие-нибудь более простые решения? Я в этой теме не разбираюсь — вполне могу о чём-то не догадываться.
Ответить с цитированием
  (#4 (permalink)) Старый
Alexiski Alexiski вне форума
Любитель давать советы
 
Сообщений: 4,276
Сказал(а) спасибо: 27
Поблагодарили 54 раз(а) в 54 сообщениях
Регистрация: 16.10.2005
По умолчанию 11.06.2010, 12:34

Совершенно непонятна вот эта фраза:
Цитата:
Другими словами, веб-сервер здесь — просто агент, никоим образом не доверенный:
Вы уж определитесь, доверенный он или не доверенный. Ведь SSL соединение устанавливает именно он, следовательно, владеет сертификатом.
Если он никоим образом не доверенный, то и сертификату его доверять нельзя, значит, весь алгоритм как-то отваливается.
Ответить с цитированием
  (#5 (permalink)) Старый
beroal beroal вне форума
Member
 
Сообщений: 108
Сказал(а) спасибо: 3
Поблагодарили 4 раз(а) в 4 сообщениях
Регистрация: 13.12.2002
По умолчанию 11.06.2010, 19:03

Если агенты работают на одном компьютере и контролируются одним субъектом, то просто все агенты и прикладной сервер доверяют друг другу. Поскольку веб-сервер преобразует данные, доверять ему необходимо. Веб-сервер сообщает прикладному серверу имя пользователя. Остальное зависит от подробностей, например, если веб-сервер и прикладной сервер связываются по интернету, то канал связи симметрично шифруется.
Чтобы сохранить простоту аутентификации, нужно уменьшить количество посредников, и всё делать в одном процессе, это также упростит исходный код ПО. :-)
Ещё было бы неплохо уменьшить количество терминов, а то трудно понять. прикладной сервер = приложение = реальное приложение. веб-интерфейс = веб-сервер. веб-серверы ⊆ агенты.
Ответить с цитированием
Ads.
  (#6 (permalink)) Старый
Samsonov Samsonov вне форума
Member
 
Сообщений: 13
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 28.04.2010
По умолчанию 11.06.2010, 20:58

Цитата:
Вы уж определитесь, доверенный ли веб-сервер или не доверенный. Ведь SSL соединение устанавливает именно он, следовательно, владеет секретным ключом. Если он никоим образом не доверенный, то и сертификату его доверять нельзя.
Вроде я нигде не писал, что SSL используется кроме как между клиентским компьютером и веб-сервером. Прикладной сервер и веб-сервер могут находиться друг рядом с другом и соединены изолированным кабелем; или вовсе располагаться в разных виртуальных машинах на одном физическом сервере. Шифрование канала между ними при этом создавало бы совершенно лишнюю нагрузку.

Ну да это не принципиально. Предположим, что веб-сервер общается с прикладным сервером тоже поверх SSL, и аутентификация прошла удачно. Что из этого следует? Что перед нами — тот самый веб-сервер. Разве это является достаточным основанием для авторизации любого запроса? Разве даёт это веб-серверу право олицетворять любого пользователя без дополнительной проверки?

Представьте себе, что на веб-сервер пробрался злобный хацкер. Мы что, должны позволить ему выполнять любые запросы только на том основании, что он орудует с аутентичного веб-сервера? Конечно, в меру терпеливый злоумышленник сможет подсмотреть многие пароли, передаваемые веб-серверу пользователями (собственно, использование клиентских сертификатов — и есть попытка уйти от передачи паролей в открытом виде и на «последней миле» тоже), но даже за месяц прослушки он соберёт лишь малую долю сведений, — так зачем же облегчать ему задачу, избавляя от необходимости вообще что-либо перехватывать?

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


Цитата:
Если агенты работают на одном компьютере и контролируются одним субъектом, то просто все агенты и прикладной сервер доверяют друг другу. Чтобы сохранить простоту аутентификации, нужно уменьшить количество посредников, и всё делать в одном процессе, это также упростит исходный код ПО.
Тогда какой вообще смысл разделять одно приложение на несколько уровней? Многоуровневая архитектура — она ведь для того и нужна, чтобы не только «утончить» каждый компонент и заложить основу масштабируемости, но и для того, чтобы повысить безопасность. Веб-сервер — он на виду, это распространённая мишень для атаки. Как его ни огораживай, всё равно шанс взлома высок. Поэтому вешать на него все функции (в том числе право авторизации) — наивно.

Цитата:
Поскольку веб-сервер преобразует данные, доверять ему необходимо. Веб-сервер сообщает прикладному серверу имя пользователя.
См. выше. Веб-сервер, конечно, выполняет посреднические задачи, но сам он по себе, без реквизитов пользователя — ничто с точки зрения прикладного сервера. Успешная аутентификация веб-сервера при подаче запроса прикладному серверу — не более чем повод начать диалог: пока агент не аутентифицируется ещё и от имени пользователя, ему позволено разве что запрашивать публично доступную информацию, не более того.

Другими словами, веб-сервер в данном случае играет роль пользовательской программы, работающей не на компьютере пользователя с графическим интерфейсом, а на выделенной машине с веб-интерфейсом. Факт успешной аутентификации самого веб-сервера — это примерно как положительный результат антивирусной проверки программы: да, ей будет позволено выполняться, но это же не значит, что той программе делегируется полномочие решать, от имени какого пользователя она будет работать, и какими правами доступа к файлам она станет ограничиваться. Вот так и тут: решать, «пущать или не пущать», должен прикладной сервер, а не агент-посредник.

<div class=\'quotetop\'>Цитата</div><div class=\'quotemain\'>Если веб-сервер и прикладной сервер связываются по Интернету, то канал связи симметрично шифруется.[/quote]Конечно, симметрично. Хотел бы я посмотреть на асимметричный SSL. :)
Ответить с цитированием
  (#7 (permalink)) Старый
beroal beroal вне форума
Member
 
Сообщений: 108
Сказал(а) спасибо: 3
Поблагодарили 4 раз(а) в 4 сообщениях
Регистрация: 13.12.2002
По умолчанию 12.06.2010, 00:33

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

Цитата:
Тогда какой вообще смысл разделять одно приложение на несколько уровней? Многоуровневая архитектура — она ведь для того и нужна, чтобы не только «утончить» каждый компонент и заложить основу масштабируемости, но и для того, чтобы повысить безопасность. Веб-сервер — он на виду, это распространённая мишень для атаки. Как его ни огораживай, всё равно шанс взлома высок. Поэтому вешать на него все функции (в том числе право авторизации) — наивно.
Не вижу оснований считать, что разделение ПО на несколько уровней повысит изоляцию между пользователями. Все пользователи пользуются одним уровнем, который работает в одном процессе. Исполнение кода в этом процессе приводит к взлому всех пользователей сразу. Многоуровневость повышает какую-то другую безопасность. Безопасность — широкое понятие.

Ещё есть вариант, что прикладной сервер может проверить корректность преобразования. Пользователь посылает подписанный запрос А. Веб-сервер преобразует А в Б. Прикладной сервер проверяет соответствие между А и Б и подпись А.
Ответить с цитированием
  (#8 (permalink)) Старый
Samsonov Samsonov вне форума
Member
 
Сообщений: 13
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 28.04.2010
По умолчанию 12.06.2010, 11:30

Цитата:
Если прикладной сервер не может проверить корректность преобразования, проводимого веб-сервером над запросом пользователя, то он должен доверять веб-серверу. Вы отвергаете очевидное решение из-за философских аргументов. Тогда задача не имеет решения.
Ну почему же?

Давайте возьмём простую аналогию из жизни. У вас есть паспорт гражданина или другое удостоверение личности, считающееся достаточно надёжным доказательством того, что вы — это вы. Ваш знакомый или родственник выдал вам генеральную доверенность и, возможно, даже дал свой паспорт. Внимание, вопрос: вы теперь авторизованы на выполнение любых операций от имени только того лица (ну, кроме тех, которые должны выполняться только лично) или от имени вообще любого гражданина страны / мира?

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

Вот так же и с агентом: да, он аутентифицируется, чтобы доказать, что не совсем посторонний. Но без «доверенности» от пользователя он не может претендовать ни на что, кроме чтения публичных данных. Пока проблема в том, что агент получает эту «доверенность» насовсем, бессрочно, — вот поэтому я и интересуюсь, как можно перейти к схеме «запрос — ответ» при работе с пользователем (да ещё к тому же вообще без необходимости помнить и вводить какой-нибудь логин-пароль), а не только при диалоге между агентом и прикладным сервером.


Цитата:
Ещё есть вариант, что прикладной сервер может проверить корректность преобразования. Пользователь посылает подписанный запрос А. Веб-сервер преобразует А в Б. Прикладной сервер проверяет соответствие между А и Б и подпись А.
Даже если представить себе, что прикладному серверу есть дело до того, по какому протоколу общается конкретная пара «пользователь — агент» (на самом деле это — их глубоко интимное дело), повторюсь, вся сложность с ЭЦП проявляется именно на стороне клиента. Уже хотя бы просто чтобы подписать запрос — это целое дело (см. мой первый постинг). А тогда уж, по-хорошему, надо бы и проверять аутентичность ответа — это вы как себе представляете?

Цитата:
Не вижу оснований считать, что разделение ПО на несколько уровней повысит изоляцию между пользователями. Все пользователи пользуются одним уровнем, который работает в одном процессе. Исполнение кода в этом процессе приводит к взлому всех пользователей сразу.
Разумеется, если кто-то взломает прикладной сервер (или сразу сервер базы данных), то он получит возможность манипулировать любой информацией. Вот поэтому, в частности, и надо было вынести прикладную логику из веб-сервера: к веб-серверу есть публичный доступ, его легко атаковать, а прикладной сервер — либо внутри закрытой сети (при наличии единственного агента), либо просто не на виду. У прикладного сервера свой протокол, свой софт, о возможных уязвимостях которого не пишут на каждом шагу. Сервер базы данных запрятан ещё глубже, и о нём публике вообще ничего не известно; атаковать его можно только с прикладного сервера. Вот такая эшелонированность.

Поймите, никто не ставит задачи добиться какой-то абсолютной защищённости — боюсь, это в принципе невозможно, если допускать возможность взлома серверов (и создание изначально злонамеренных агентов) и сохранять удобство пользования для людей: больше автоматизма, меньше ручных операций, в том числе подтверждений. Задача состоит в том, чтобы свести риски к разумному минимуму, не прибегая при этом к каким-то особо извращённым методикам.
Ответить с цитированием
  (#9 (permalink)) Старый
beroal beroal вне форума
Member
 
Сообщений: 108
Сказал(а) спасибо: 3
Поблагодарили 4 раз(а) в 4 сообщениях
Регистрация: 13.12.2002
По умолчанию 12.06.2010, 16:21

Цитата:
Вот так же и с агентом: да, он аутентифицируется, чтобы доказать, что не совсем посторонний. Но без «доверенности» от пользователя он не может претендовать ни на что, кроме чтения публичных данных. Пока проблема в том, что агент получает эту «доверенность» насовсем, бессрочно
Теперь вы сформулировали вопрос по другому. Нужно, чтобы веб-сервер был авторизован временно? Пользователь сообщает о начале и конце авторизации прикладному серверу напрямую. Конечно, в период между началом и концом веб-сервер может подать от имени любой запрос по своему желанию — это та проблема, которая неразрешима.

Цитата:
Даже если представить себе, что прикладному серверу есть дело до того, по какому протоколу общается конкретная пара «пользователь — агент» (на самом деле это — их глубоко интимное дело), повторюсь, вся сложность с ЭЦП проявляется именно на стороне клиента. Уже хотя бы просто чтобы подписать запрос — это целое дело (см. мой первый постинг). А тогда уж, по-хорошему, надо бы и проверять аутентичность ответа — это вы как себе представляете?
Схема рабочая, но я думаю, что она вам не нужна, поэтому этот вопрос закрыт.

Цитата:
Сервер базы данных запрятан ещё глубже, и о нём публике вообще ничего не известно; атаковать его можно только с прикладного сервера. Вот такая эшелонированность.
Вы читаете, что я пишу? Об изоляции пользователей. Речь идёт об аутентификации пользователей, о защите от взлома аутентификации. А вы об эшелонированности. Это совершенно разные вещи. То есть этот вопрос закрыт. Поменьше увлекайтесь расплывчатыми философскими аргументами.
Ответить с цитированием
  (#10 (permalink)) Старый
Samsonov Samsonov вне форума
Member
 
Сообщений: 13
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 28.04.2010
По умолчанию 13.06.2010, 13:33

Цитата:
Нужно, чтобы веб-сервер был авторизован временно? Пользователь сообщает о начале и конце авторизации прикладному серверу напрямую.
Как вы это себе чисто технически представляете, если:
  • клиент в большинстве случаев — обычный веб-браузер;
  • прикладной сервер, в случае наличия единственного веб-сервера, недоступен из публичной сети?
Да и полагаться на то, что у клиента всегда будет возможность подать сигнал об окончании сеанса работы — чересчур самонадеянно. По-хорошему, «доверенность» должна автоматически истекать через время, необходимое на обработку самого длительного запроса. То есть она должна выдаваться при каждом запросе — вот почему неинтересен вариант, когда пользователю каждый раз надо что-то вручную подтверждать.

Цитата:
Я вам пишу об изоляции пользователей.
А я не знаю, зачем вы о ней пишете. :)

Вопрос был, напомню, о возможности «транзитной» аутентификации на основе открытых ключей (тех же, что используются для установления SSL-туннеля) — чтобы клиент подписывал некую строку текста, полученную им от веб-сервера (с которым он установил SSL-туннель), но которую сгенерировал не сам веб-сервер, а прикладной сервер. И при этом чтобы клиенту не приходилось устанавливать никаких дополнительных программ, чтобы этот механизм никак не зависел от конкретного веб-браузера, и чтобы пользователю не надо было совершать кучу лишних телодвижений при каждом запросе.

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


Цитата:
Речь идёт об аутентификации пользователей, о защите от взлома аутентификации. А вы об эшелонированности. Это совершенно разные вещи.
Эшелонированность для того и применяется, в частности, чтобы взлом фронтэнда (или создание собственного изначально злонамеренного) не приводил к моментальной компрометации всех данных.

А то, о чём вы говорите, — о какой-то мифической «изоляции пользователей на уровне программных процессов», — это вообще непонятно что и с боку бантик. Чтобы так изолировать пользователей, надо каждому дать отдельную систему с собственной БД и собственным агентом доступа к данным. Ну, и кому такое разобщённое чудо-юдо нужно?
Ответить с цитированием
Ads
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Trackbacks are Вкл.
Pingbacks are Вкл.
Refbacks are Выкл.


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Как сделать ssh аутентификация sh dartwader Общие вопросы программирования 0 24.03.2008 14:03
Аутентификация на прокси North Сетевое программирование 1 11.05.2006 17:27
Программная аутентификация пользователя под Linux cubereality C++ на Unix 7 06.03.2006 06:58
Аутентификация на SMTP сервере imported_Sergei Delphi 2 31.12.2005 14:24
MS SQL Server аутентификация Tokarev Vyacheslav MSSQL Server 0 07.12.2005 17:48
Как происходит аутентификация по протоколу http Anonymous Visual C++ 0 30.01.2004 17:10
Аутентификация и подключение к БД Oracle Anonymous PHP 0 16.07.2003 09:37



Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Нardforum.ru - компьютерный форум и программирование, форум программистов