Методика хука HTTP/HTTPS в ИЕ и ФФ.

Что за сеновал ?

Читал, но до практики пока не дошло, потому смутно понимаю всю схему. Смотрю исходники ФФ. Если ФФ может расшифровывать/зашифровывать трафик, значит он получает все что нужно от сервера ? Значит, ничего невозможного в этом нет...

 

Когда я последний раз смотрел фф под отладчиком, там _не_ юзался ws2_32!recv там другая ф-ция юзается)

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

 

Зачем отладчик ? Смотрел сырцы недавно, вроде винсок он юзает.. Ну, когда я делал хуки винсока, я перехватывал трафик ФФ.

Ну тогда просто отдать ему незашифрованный трафик сразу и он подумает, что на https сервере, висит простой сервер.. Там же заголовки у TLS свои, через Wireshark глянь..
Просто косяк, что он у юзера не будет подтверждений спрашивать на счет сертов и значка в строке браузера не будет, что соединение защищенное..

 

2FED
А то, есть получая сертификат от сервера, клиент генерирует случайное значение ключа, которым шифрует все сообщения, который он серверу не передает ? А сервер на основание своего закрытого ключа может его расшифровать? Я правильно понял? Если этот случайный ключ не передается по сети, то расшифровать сообщения уже нельзя

 

Ну посмотрите вы уже исходники OpenSSL/YaSSL/axTLS/etc. наконец-то.
Wiki почитайте: http://en.wikipedia.org/wiki/Secure_Sockets_Layer

 

Вообщем понятно, что без приватного ключа ничего не получится расшифровать.
А как на счет того, чтобы сэмулировать работу сервера у себя, в то же время общаясь с реальным сервером. То есть, когда клиент будет запрашивать безопасное подключение, самому генерировать сертификат нужный, возвращать его клиенту, где мы уже будем иметь приватный ключ, а с удаленным сервером уже работать по честному, получится, что то вроде прокси, от клиента мы будем расшифровывать данные, потом зашифровывать другим ключом и отправлять серверу, а от сервера ответ расшифровать, зашифровать опять другим ключом и клиенту. Это вроде называется MitM-атака?

 

Я как раз тоже думал о том что можно эмулировать и браузер и сервер но решил что это уж слишком бредовая идея ))
В теории все просто...

 

ну так а чем вариант не подходит? работа как пишут _гигантская_, но реализовать MitM разве будет проще?

 

Proxomitron (если кто знает такую прогу) работает как локальный прокси и фильтрует HTTPS путем MITM используя свой серт.

 

MITM в https бесполезны - сертификаты..

Каким же?
Ничего тут не сделаешь, единственный вариант - засовывать свой серт, а в браузере ставить доверенным CA.
Только это ещё более бессмысленно наверное будет..

Хм, а какой толк, что что-то будет крутится у себя? Браузер все равно увидит твой криво-подписаный серт

 

а если есть исходники фф почему бы не посмотреть место в коде где происходит дешифрация и поставить туда хук?

зашифрованый трафик > процедура расшифровки > наш хук > вывод на экран

 

Большая часть сертов, в интернете самоподписные, и что ? Ты же жмешь, принять все равно.. При чем, как то же он проверяет подпись на verisign или где он подписан, что мешает перехватить этот запрос и дать положительный ответ ?

Глупость! Видать все троянцы, которые были написаны в этом направление, не работают ?
Сертификаты сохраняются у браузера, при первом конекте, чтобы потом юзера не спрашивать, доверять серту или нет, затем происходит все то же самое, и если фф тот же сайт, вернет другой сертификат, он опять будет спрашивать пользователя.

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