Есть программа, которая по SSL общается с сервером. Её никак нельзя поменять, но можно настроить сайт, по которому она будет ломиться. Проблема в том, что она после установки SSL-соединения проверяет сертификат на hash и issuer (они забиты в программе, как и порт соединения 443).
Я хочу написать некий прокси-сервер, который будет перенаправлять рукопожатия напрямую (там асимметричное шифрование, так что пусть SSL-соединение устанавливают сами, заодно и сессионный ключ узнаю), а вот на этапе передачи данных, когда уже используется симметричное шифрование, подсуну свой ответ от сервера.
Возможно ли провернуть такую аферу? Участвует ли приватный ключ сервера при обычном
обмене данными (с симметричным шифром)? в гугле толком не могу найти, а в исходниках openssl чёрт ногу сломит

| Сообщение посчитали полезным:

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

-----
старый пень

| Сообщение посчитали полезным:

даже если я не буду знать симметричный ключ, знание исходных данных, и зашифрованных позволяет получить ключ? на то он и симметричный шифр?
правда, известно только начало сообщения, около 16 байт "RegisterDevice={"
(пока что не знаю, что конкретно посылается от клиента)

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

| Сообщение посчитали полезным:

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

ps. обмен данными можно подсмотреть используя программы: fiddler2, charles web-proxy - это простой способ (работает не всегда, как правило если жестко забиты IP-шки или хуки какие), более сложный - качаем backtrack r5, настраиваем на нем форвардинг и NAT, пускаем arpproxy и sslstrip, трафик идет в реальном времени через sslstrip и расшифровывается в лог
ps. почему polarssl? потому что он прост как 5 копеек
ps. в процессе передачи никакой приватный ключ не нужен, весь обмен идет по публичным ключам

| Сообщение посчитали полезным:

можно еще вот это попробовать... лично, я отказался от этого варианта и пошел по пути описанному выше
http://www.codeproject.com/KB/IP/HTTPSDebuggingProxy.aspx

| Сообщение посчитали полезным:

drone
Автор пишет: "... проверяет сертификат на hash и issuer (они забиты в программе..."
В таком случае MITM не реализуется без соответствующего патча.

[wl]
"знание исходных данных, и зашифрованных позволяет получить ключ? на то он и симметричный шифр?"
С какой это стати? Выбирается самый сильный из поддерживаемых обеими сторонами шифр. AES, например.

-----
старый пень

| Сообщение посчитали полезным:

[wl] пишет:
Я хочу написать некий прокси-сервер, который будет перенаправлять рукопожатия напрямую (там асимметричное шифрование, так что пусть SSL-соединение устанавливают сами, заодно и сессионный ключ узнаю), а вот на этапе передачи данных, когда уже используется симметричное шифрование, подсуну свой ответ от сервера.
Этот прокси-сервер будет исполняться на одной системе с программой и может получить доступ к ее памяти? Если да, то возможно. Если нет, то только патч проверки hash и issuer и MITM полной подменой сертификата. Второе даже проще.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

r_e, согласен, в данном случае патч нужен будет либо проверок, либо самого сертификата публичного

| Сообщение посчитали полезным:

мда, насчет AES я что-то не подумал...
Доступа к памяти программы нет, получается, атаку не провести. Досадно...

| Сообщение посчитали полезным: