Пару сетевых вопросов. 1. Есть некий бинарный протокол, который стабильно и хорошо работает для связи клиент-сервер через интернет. Если его обернуть в SSL соединение, то какие могут возникнуть трудности? Может быть так что в результате чего-то SSL соединения на компьютере какого-то пользователя не будут работать? 2. Если злоумышленник изменит адрес SSL соединения в программе-клиенте на свой, что это даст злоумышленнику; Можно ли будет узнать входящий и исходящий траффик, путем например постепенного анализа: изменить адрес SSL сервера на свой, законнектится к нему, - на сервере посмотреть какие данные клиент отправляет серверу. Потом делать свое SSL соединение, отдавать серверу данные полученные в прошлом шаге, посмотреть что ответит сервер и т.д.? Как SSL клиент проверяет что его коннект идет с доверенным сервером, а не с подделкой? Спасибо.
Если использовать сертификаты, то клиент и сервер могут идентифицировать друг друга по ним (ищи с гугле авторизацию по клиентским ssl сертификатам), но ведь ничто не мешает злоумышленнику подменить сертификат на свой и дальше творить свои злодеяния. Можно сильно осложнить ему задачу, выполняя критичный код на сервере, тогда ему придется сильно потрудиться чтобы понять что к чему.
Если сервер не поддерживает https. На стороне клиента только одно может помешать - сертификаты. Тут длинная песня. Например, клиент желает использовать только подписанные сертификаты, а покупать их не хочет
Спасибо. Я попробую почитать про сертификаты. Но если мы имем допустим веб браузер, открваем в нем https://google.com. Каким образом конечный пользователь браузера может быть уверен в том, что это реальный google.com, а не подмененый где-то в пути с его компьютера? Можно ли в таком случае вообще подменить данные в SSL и получить ситуацию обмана?
waxman2 Когда ты открываешь https://какой нибудь сайт, и браузер не ругается, это значит что сертификат, по коророму работает этот сайт (и внутри которого в поле common name жестко прописано его доменное имя) подписан доверенным издателем, в случае с google это Thawte. Корневые сертификаты таких контор как Thawte, Verisign помещаются в виндовое хранилище, браузер при получении сертификата от сервера ищет в хранилище корневик, которым он подписан, проверяет цифровую подпись и если все ок, то не бухтит и пускает дальше. Если же корневого сертификата, которым подписан тот, что выдает браузер нет в хранилище, то увы и ах. Можно сгенерить свой самоподписанный сертификат, установить его в хранилище винды, и тогда он будет корневым доверенным.
Поэтому, кстати, при заходе на https://google.com он ругается. потому что в сертификате прописано www.google.com, а это две разные вещи. Конечно же можно приобрести сертификат типа *.google.com, такие сертификаты называются wildcard
Scratch, спасибо за объяснение. Но опять я не понял: браузер посылает запрос на https google, а я где-то в это время перенаправляю этот запрос и своим сервером отдаю сертификат, который отдает google.com. В результате этого получится подмена или это как-то контроллируется?
waxman2 нифига не получится. Ты отдашь чей сертификат? Свой, потому что гугловский ты отдать не можешь. Помимо сертификата, который ты видишь, есть еще закрытый ключ, которым гугл расшифровывает заросы, зашифрованные по открытому ключу, хранящимуся в сертификате. А раз ключа у тебя нет, то ты обламаешься. Если же ты подсунешь самосгенеренный сертификат, то его подпись будет далека от подписи thawte, и браузер ругнется. Что и требовалось доказать
