привет спецам,

можно ли на уровне провайдера сниффать HTTPS-трафик между клиентом и защищенным сайтом, если сертификат на сайте общедоступен?
расскажите, плз, как оно работает, или дайте RTFM.

спасибо!

сниффить можно, но только в зашифрованном виде.

в общем идея такая:
сначала была система основанная на 2-х ключах: публичный и частный.

Публичным ключом твои друзья шифруют информацию.
Частным - ты ее дешифруешь.

т.е. для дешифровки нужен частный ключ.

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

Для этого придумали PKI, т.е. инфраструктуру распространения.
Создали компутер под названием CA (certificate authority).
и он подписывал все публичные ключи. Для того, чтобы узнать, получив публичный ключ - тот ли человек, за кого выдает себя, нужно было зайти на сервер CA, и там есть список валидных.


для того, чтобы их подписать, нужно физически доказать свою личность перед CA.
т.е. для того, чтобы шифровать/подписывать тебе письма мне нужно было подключиться к CA, проверить, что твой сертификат ВАЛИДЕН, и шифровать.
Но для дешифровки, ты свой частный ключ всё еще держишь у себя.

что происходит между веб-сервером и клиентом ?

1. ты получаешь его публичный ключ
2. он получает твой публичный ключ 

твои сообщения может расшифровать только он, а его - только ты.

ISP может иметь только публичные ключи.
Частный ключ ни один уважающий себя сервер им не даст.

На уровне провайдера можно не просто снифить, а дешифровать трафик.
Принцип действия:
Сервер-посредник, представляющий из себя роутер, а ещё лучше прокси, выступает в роли сервера и клиента.
Для клиента он сервер, для сервера клиент.
Получает от сервера открытый ключ сервера, передаёт вместо него клиенту свой ключ.
Клиент шифрует данные ключём посредника. Отправляет.
Посредник дешифрует данные. Шифрует ключём сервера. Отправляет.
Обратный порядок тот же.
Если ключ защищён сервером проверки сертификата, тут задача усложняется.
Здесь есть разные методы обхода. И все непростые.
Но как правило они редко применяются.
Браузер просто спросит, а точно ли вы доверяете данному источнику...
Ситуация привычная. И юзер жмёт "Да".
Многие, даже уважаемые сервера, вообще не имеют подтверждённого сертификата, и используют самопальный незащищённый.
Всё равно все соглашаются.
В крайнем случае можно установить свой собственный центр сертификации и зарегестрировать его в системе.

Хочу уточнить, что данная атака носит название MITM (Man-In-The-Middle). Информацию по ней можно найти достаточно просто. Даже готовые прокси есть: 

Achilles
DeleGate
Proxomitron

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

блин, не заметил, что Snowy уже написал про это немного 
ладно, другая формулировка от меня, пускай будет 

т.е. вы предлагаете атаку man-in-the-middle.
Да, это может сработать только с анонимными клиентами к защищенному серверу.
там действительно большинство юзеров не смотрит что за сертификат, кто его CA, не идет в список электронных подписей сертификатов, подписанных данным CA. 
Согласен.

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

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

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

Для этого нужно либо полностью обдурить пользователя, т.е. украсть его сертификат с помощью разных нестабильных техник (напр. javascript, activeX control),
либо (если юзер защищается: NoScript, Firefox,  
SElinux, и т.д. ) у ISP хрен чего получится.

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

И еще один момент: 
на первом окне сообщения о предупреждении пишется о несоответствии сертификата с именем хоста. 
1) Если сертификат от ebay  а имя хоста от xommunications.ru, то пользователь рано или поздно просекет.
2) Если ISP будет уличен в DNS spoofing, его турнут.
3) нередко для основания коммуникации SSL, кроме сертификата пользователя, нужен также и сертификат хоста.
4) 

Вот именно. пользователь по идее не должен будет получать от корректного сервера никаких сообщений об ошибках. а сертификаты серверов CA ему установит администратор его фирмы.




arilou, а чем основан ваш изначальнык вопрос ?

HTTPS позволяет организовать какую-то другую схему?

Беспокоит немного безопасность высказывания мнения в моей стране .

Добавлено через 1 минуту и 30 секунд

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

http://en.wikipedia.org/wiki/X.509

только, если вам действительно нужно организоваться на такое дело, стоит использовать хэш не md5, а sha1.

Мир вам.

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

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

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

Двусторонняя ауетнтификация предназначена исключительно, как средство аутентификации клиентов. Для предотвращения MITL предназначены доверенные сертификаты.

согласен на все 100%. мы просто рассматривали как можно избежать атаки mitm исходя из HTTPs.
т.е. "какие средства нужно для идентификации сервера и клиента "надеть" на HTTPs"
мы же говорим:

и


не знаю что W4FhLF имел ввиду, но я именно это и имел ввиду: что сертификаты получаются до попытки установки связи с данным сервисом. и когда ты подключаешься, у тебя уже стоят "галочки" доверенности сертификата. т.е. если у тебя выскакивает какое-то предупреждение при соединении, а не запрос послать один из твоих пользовательских сертификатов, то что-то уже нехорошо пахнет.

<cut>

Это сообщение отредактировал(а) Alexandr87 - 20.1.2008, 08:45