LINUX.ORG.RU
ФорумAdmin

Перехват HTTPS-трафика


0

0

Нужно узнать,что отвечает сервер на HTTPS-запрос. Соответственно, Wireshark по-моему не катит (не расшифрует же), так что не знаю... чем бы воспользоваться в этих целях? Думаю, может, через прокси какой или редирект сделать на подставном Apache посередине между клиентом и реальным сервером?
Подскажите, как нам обустроить РабКрин, очень надо среверсынжирить один протокол.

★★★★★

Нужно узнать,что отвечает сервер на HTTPS-запрос.

openssl s_client -server apache.ssl.host -port 443
GET /

Думаю, может, через прокси какой или редирект сделать на подставном Apache посередине между клиентом и реальным сервером?

Вообще-то SSL был придуман для того, чтобы MitM атаку реализовать было бы очень сложно. Ага?

zgen ★★★★★
()

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

markevichus ★★★
()

Нет

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

А вообще, если эта дыра закрыта (renegotiation запрещен), MitM ничего сделать не может, разве что заблокировать трафик вообще. На то это и SSL :)

Впрочем, можно попытаться найти место, где клиент держит CA сервера (или CA того, кто его подписал) и попытаться подсунуть свой CA.

anonymous
()
Ответ на: Нет от anonymous

Впрочем, можно попытаться найти место, где клиент держит CA сервера (или CA того, кто его подписал) и попытаться подсунуть свой CA.


Ну-ка еще раз, а то я эту часть не понял :)

zgen ★★★★★
()
Ответ на: комментарий от zgen

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

true_admin ★★★★★
()
Ответ на: комментарий от zgen

>Ну-ка еще раз, а то я эту часть не понял :)

Ну, допустим, прога идет по SSL на https://mail.google.com. Гугель ему предъявляет сертификат на оный домен, подписанный Thawte SGC (тоже гугель, кажется :)). У клиента уже должна быть своя копия CA thawte, при помощи которой можно проверить аутентичность гуглового сертификата и сделанной им (точнее, его закрытым ключом) подписи данных. Гугловому сертификату соответствует закрытый ключ (который есть на сервере гугла, но у нас его нет). Зашифрованные его сертификатом данные можно расшифровать только его закрытым ключом. Подписанные его закрытым ключом данные можно проверить его сертификатом.

Военная хитрость состоит в том, чтобы подсунуть вместо сертификата thawte свой, и им же подписать свой сертификат на имя гугла, после чего можно делать SSL-прокси. Клиент посчитает нас за гугл, а мы перед гуглом притворимся клиентом. Это и будет MitM в полный рост :)

// Возможно, где-то наврал. Все-таки я не супер-спец по криптографии %)

anonymous
()
Ответ на: комментарий от thesame

только сертификат твой будет неподписанный, и браузер будет вопить

CA-сертификаты все самоподписные, если они верхнего уровня :-)

undertaker ★★
()
Ответ на: комментарий от undertaker

Так вроде у каждого браузера внутри неонка набор сертификатов основных CA, так что, по-моему, всё равно не прокатит.

berrywizard ★★★★★
()
Ответ на: комментарий от berrywizard

Так если мы имеем доступ к браузеру пользователя, значит, и в это хранилище доступ тоже имеем :-)

undertaker ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.