Безопастность SSL... есть ли вероятность обмана?

← →
sniknik © (2011-12-16 12:21) [0]

Используется схема с само-подписанными сертификатами, т.е. удостоверяющего общего центра нет. Но так же, сертификаты не выдаются, "по требованию". Только в длительном процессе с участием менеджеров (т.е. считаем тут "дырки" нет ;), т.к. запрос о принципиальной возможности пришел от них, и виноваты могут быть естественно кто угодно не не они LOL)
Ну вот, считаем значит, что у клиента есть пара "ключ-сертификат" + пароль на его использование. Правильная пара, иначе все рассуждения не имеют смысла. На сервере есть вторая половинка ключа. Используются только они, никаких дополнительно высланных.
Ну и вот, можно ли подделать сервер, т.е. сделать так чтобы клиент имеющий "честные ключ-сертификат", ошибочно/по злому умыслу/неважно подключился к чужому серверу, не имеющему "второй части", и чтобы этот сервер игнорируя ошибки, и отсутствие части ключа, на "рукопожатии" сказал, да фигня, все ок, давай общаться... и стал работать с клиентом ???

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

← →
Медвежонок Пятачок © (2011-12-16 12:52) [1]

Если даже и есть такая возможность, то к вам-то какие претензии?

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

← →
Медвежонок Пятачок © (2011-12-16 12:55) [2]

В том смысле, что если произойдет успешная атака по описанной в вопросе схеме, то это значит, что злоумышленник подломил что?
Правильно.
Он подломил браузер клиента, а не сертификаты или сервер. То есть подломил не что-то ваше, а что-то потустороннее.

← →
Медвежонок Пятачок © (2011-12-16 13:02) [3]

Либо вообще проще и абсурднее можно ситуацию придумать.

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

Что подломлено в этом случае?
Опять только моск самого юзера.

← →
Медвежонок Пятачок © (2011-12-16 13:26) [4]

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

Теперь по сути вопроса.
Ясно, что речь идет не о самой "защите всего", а о разделении ответственности внутри конторы "в случае чего".

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

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

Если юзер прошел квест (по мнению манагеров) - манагеры делают отметку в акте передачи ключей и выдают все что должны выдать.

Итог:
в случае описанном в [0] крайними будут не разрабы, а хитрожопые манагеры, которые сейчас заранее хотят прикрыть свой зад.

← →
sniknik © (2011-12-16 14:14) [5]

> Если даже и есть такая возможность, то к вам-то какие претензии?
Сайт "выдает деньги"/услуги, т.е. схема - кто-то их принимает, говорить ок, а претензии о не выдаче/не выполнении услуг идут к управлению "правильного".

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

> крайними будут не разрабы
Разрабы могут быть "левыми", а вариант клиента с игнорированием ошибки от корневого сертификата в принципе возможен. ;(

> дать манагерам тот самый "поддельный" сервер, который будет тоже ваш.
Уже проверили, сами, наши клиенты "отбились". Т.е. с ними все ок.

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

Хотя это не отменяет первой части с их характеристикой. :))

← →
Медвежонок Пятачок © (2011-12-16 14:19) [6]

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

и она никак не обусловлена стойкостью самого ssl.

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

но ситуация-то не та.
регламенты и правила ты можешь придумать, но не можешь контролировать их соблюдение на стороне клиента.

а раз не можешь контролировать, то и отвечать за уязвимости клиента (как человека) ты не можешь.

← →
sniknik © (2011-12-16 14:21) [7]

> Опять только моск самого юзера.
Моск юзера может быть девственно чистым, без извилин... пофигу, это программа клиент не должна вестись на левые сайты.
Т.е. должен быть регламент как использовать сертификаты чтобы все было ок. Если уж нельзя быть уверенным, что без корневого сертификата, у левых сайтов без проверки клиентом каких то условий можно "попасть".

← →
sniknik © (2011-12-16 14:23) [8]

> но ситуация-то не та.
Вообще-то именно та, я говорю именно от имени бакра... он в россии. Значит банк россии. ;)

← →
Медвежонок Пятачок © (2011-12-16 14:32) [9]

Клиент банк чтоле?
Через браузер?

все равно не та ситуация.
я имел ввиду когда цб регламентирует работу с ним самим остальных кредитных организаций.

в этом случае он может требовать, чтобы рабочее место было в темной комнате с синими шторами, чтобы работала девственница не моложе сорока лет и не в периоды овуляции.

может требовать и может контролировать.

но ты-то не можешь, так как это хоть и твой клиент, но он не твой подчиненный.

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

← →
Медвежонок Пятачок © (2011-12-16 14:36) [10]

Если уж нельзя быть уверенным, что без корневого сертификата,

так в том то и дело.
манагеры боятся, что клиент попадет на бабки потому что "наверное ссл ненадежно".
а клиент может попасть на бабки даже если ссл абсолютно надежно.

← →
sniknik © (2011-12-16 14:37) [11]

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

> короче если клиентская программа - это браузер, то ничего с этим поделать нельзя.
.... Как бы, не исключена такая возможность, но пока нет. Значит, раз нельзя пишем - нельзя делать клиент в браузере.

← →
Медвежонок Пятачок © (2011-12-16 14:39) [12]

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

но это уже мое имхо.

← →
sniknik © (2011-12-16 14:42) [13]

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

← →
Медвежонок Пятачок © (2011-12-16 14:42) [14]

если клиент самописный, то не все так печально.

например:
не используем схему: закрытый канал + открытые данные.
а используем схему : любой канал(открытый или закрытый) но данные обязательно закрыты на прикладном уровне.

тогда подделывать сервер просто заколебешься.

← →
sniknik © (2011-12-16 14:44) [15]

> через браузер (в условиях россии) - это небольшая бессмыслица
Короче, забыли браузер, возвращаемся к основному вопросу. :)

> но это уже мое имхо.
Нас, как минимум, двое. ;)

← →
sniknik © (2011-12-16 14:49) [16]

> тогда подделывать сервер просто заколебешься.
Протокол шифрации данных должен быть открытым... т.к. -
> по которому в принципе любой может сделать своего клиента... вот и проблема. ;(

Со своим клиентом проблем нет достаточно проверять ответ по корневому сертификату.

Ок.
Вот схематично:

клиент обменивается с сервером по открытому каналу.
В моем случае это обычный http/post
в заголовках ничего такого нет, на чтобы обращали оба.
все внутри пост-данных, которые закрыты и подписаны.

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

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

кроме того, для подделки протокола надо как минимум расшифровать пакеты, и вот это уже вопрос стойкости криптолибы.

> хакер может стоять посередине и подсовывать ранее перехваченные и серверу и клиенту, но они оба сразу это прочухивают.
Меня не сквозная работа через подделку волнует, а вообще ответ от подделки типа "ок, выдавай деньги", из-за которого будут проблемы у обоих. Участие оригинального сайта можно не учитывать.

"Соль" не хороший вариант, хотя бы потому, что нужно либо зашивать в программу/либо алгоритм, и что узнается 1 раз и весь принцип насмарку.

Так клиент-то понимает что серверный пакет не родной.

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

> sniknik (16.12.2011 14:49:16) [16]

Протокол шифрации данных должен быть открытым... т.к. -
> по которому в принципе любой может сделать своего клиента... вот и
> проблема. ;(

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

> Защита основанная на секретности
> ...
Это было сказано на -
> тогда подделывать сервер просто заколебешься.
Типа, какое там "заколебешься" если правила шифрации, и как она делается/должна, будет в открытом виде.

> sniknik (16.12.2011 16:36:21) [21]

Открытости не надо боляться, это надо приветствовать.

правила шифрации могут быть в открытом виде.
но пакет-то надо сначала расшифровать, чтобы написать свой поддельный сервер.

Безопастность SSL... есть ли вероятность обмана? Найти похожие ветки