Есть программа, которая работает через HTTPS. После запуска она принимает данные с сервера. Мне надо менять только 1 цифру в ответе сервера, но каждый раз запускать charles не считаю удобным. Решил использовать freecap+proxomitron. С первым проблем не возникло, а proxomitron в упор не пускает в Интернет программу если включить поддержку ssl в настройках . При попытке зайти на какой-то сайт через браузер получаю ошибку

Код:

Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.

Грешил на фрикап, proxifier работает так же — значит проблема в proxomitron. Не знаю что делать, с включенным ssleay/openssl не открывается вообще ничего. Помогите пожалуйста.

Поддержка SSL в Проксе не совсем очевидная. Начиная с того, что есть 2+ режима, и заканчивая необходимостью дополнительных библиотек и свежих сертификатов...

Я сам не пользуюсь, так что могу только посоветовать почитать темы форума с SSL или HTTPS в названии. Вот, например (файлы sidki переехали сюда).

Спасибо за ответ. Я уже искал по форуму критериям "https" и "ssl", но не встречал проблему, похожую на мою.

Последние dllки и БД уже закинул в папку proxomitronа, свой proxcert.pem создал еще вчера, но режим фильтрации так и не работает — ни у одного приложения нет доступа к интернету. Режим Pass-through мне не нужен.

Andrik писал(а):

не встречал проблему, похожую на мою.

Я тоже. Может, это не с Проксом проблема? Проверь работу "прямой" цепочки без дополнительных прокси: браузер -- Proxomitron -- https-сервер. (Для чистоты эксперимента в Проксе желательно отключить всю фильтрацию.) Если получится, то пробуй то же самое со своей программой.

Andrik писал(а):

При попытке зайти на какой-то сайт через браузер получаю ошибку Код: Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.

Цитата:

браузер -- Proxomitron -- https-сервер

уже делал так - не работает. в режиме pass-thru все работает, но мне нужна фильтрация https. цепочка такая: инет-Проксомитрон-брузер или *нужная мне программа*-freecap или proxifier-Прокс-инет

Добрый день.

Раньше, насколько я помню, не было проблем с изменением содержания защищенных (https) страниц.
Сейчас возникла такая необходимость, стал пробовать и такое впечатление что Прокс вообще не видит код страницы, не срабатывает даже простейший фильтр:

Код:

Name = "Saved from URL (end) [EAH]" Active = TRUE URL = "$TYPE(htm)" Limit = 8 Match = "<end>" Replace = "\r\n<!-- saved from URL: \u -->\r\n"

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

Пробовал, например на

Код:

https://mail.google.com/

Нет ни добавки в конце кода страницы, ни строчек о срабатывании фильтра в логе Прокса.

От браузера это не должно зависеть, тем не менее проверял на Хроме и ИЕ.

На обычных страницах работает все как надо.
С сертификатом безопасности Прокса все нормально, браузеры не ругаются и в логе тоже ругани нет (как было до обновы сертификата).

Кто-нибудь с этим сталкивался и, самое главное, знает как заставить Прокс по прежнему работать с защищенными страницами?

Проверь настройки прокси - для http и https они разные.

Alex Qwerty писал(а):

Проверь настройки прокси - для http и https они разные.

Это намек что браузер получает страницы минуя Прокс?
Нее, не может такого быть - я в логе Прокса вижу запросы браузера и ответы сервера.

Есть ли возможность у вас или у кого-нибудь еще проверить на той же стартовой странице гуглевской почты срабатывают на ней правила Прокса или нет?
Потому что я понимаю что должны работать, но ведь не работают!

А в настройках Проксомитрона разрешил? Старые библиотеки OpenSSL ему подкинул? Возможно еще потребуется старая версия zlib...

Цитата:

А в настройках Проксомитрона разрешил?

Когда я это прочел, то ответил - конечно, да!
Но полез проверить и к своему удивлению увидел на последней закладке настроек что галочка "Использовать SSleay/OpenSSL ..." не стоит.
Когда я ее поставил то в ответ получил сначала одно окошко Прокса:

Цитата:

Sorry, This version of SSleay doesn't contain all the needed functions. It may be too different a version or complied without all the necessary algorithms.

закрыв которое еще одно:

Цитата:

OpenSSL_add_all_algorithms.

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

Я же считал что Прокс в первом сообщении предупреждает об нехватке необходимых функуций в библиотеках, а вторым уведомляет что они добавлены я конечно удивился откуда он смог их добавить..., но порадовался насколько он умный...
Поэтому-то у меня было все "нормально с сертификатом, но не работал Прокс".

Теперь возникает проблема с правильным сертификатом.
У меня есть два сертификата действительные по времени, в одном издатель:
"Proxomitron" - созданный с помощью батника из комплкта sidki.proxfilter.net/prox/ssl-stuff/make-proxcert.zip
во втором "Internet Widgits Pty Ltd" - созданный по инструкции с ру-боарда от WRFan'а (и самой свежей openssl.exe)
Оба установлены в корневые сертификаты, еще один действительный от издателя "Proxomitron" и один старый от издателя "SRL" (выданный тоже для Proxomitron)

И пять комплектов ssleay32.dll/libeay32.dll один из которых самый свежий.

Код:

1. Шли в комплекте с Проксом ревизия 0.9.7e 25 Oct 2004 -- дата файлов от 27 октября 2004 года  -- MD5 30acef967a42b542c851221a067f68ec / 43fd129c4242fe70c85a05e176e70690 2. Из комлекта "openssl-0.9.8-mod-rev1.zip" ревизия 0.9.8 05 Jul 2005  -- дата файлов от 26 сентября 2006 года -- MD5 fa4e50ec3624a058725e2a98b3946f2e / d370853dceddccc520c16074add42898 3. Из комплекта http://sidki.proxfilter.net/prox/ssl-stuff/make-proxcert.zip ревизия 0.9.8 05 Jul 2005  -- дата файлов от 6 июля 2005 года      -- MD5 b68cfaeaf9482fdf1d27cabdba16f66d / 0153e2adff5bd04e5c32a15188baaf51 4. Самые свежие файлы мая этого года с http://slproweb.com/products/Win32OpenSSL.html ревизия 1.0.0j             -- дата файлов от 10 мая 2012 года      -- MD5 65f06691b84362f6568f039c8b9d1ca3 / 936ff2866373d1805123df114941794f 5. Не помню где достал, но судя по дате может тоже в одном из комплектов Прокса были ревизия 0.9.6m 17 Mar 2004 -- дата файлов от 18 марта 2004 года    -- MD5 549bf453384251092f19be05a11b3808 / 653b5be8990fb76f00153b3243e2d346

Ни в каких комбинациях библиотека/сертификат - не получается нормально работать по https

С самыми свежими библиотеками не работает вообще - появляются те два окошка предупреждения и контент страниц вообще Проксом не трогается.
С четырьмя другими комплектами библиотек не работает по другому - браузеры ругаются на не действительный сертификат и предупреждают о возможной попытке видоизменения получаемого мной контента. Причем, если ИЕ предупреждает о недействительности сертификата, но все равно оставляет возможность работы по https (и фильтры срабатывают на странице), то Chrome просто не пускает, отказываясь открывать страницу (до обновления его до последней версии - он тоже оставлял ссылку по которой можно пройти с неправильным сертификатом). А поскольку Chrome у меня основной браузер, то вариант "мириться с предупреждениями в ИЕ" меня не устраивает.

Теперь собственно вопрос - где взять рабочий комплект сертификат+библиотеки?
То что не помогает "make-proxcert.zip" не означает ли что надо патчить "под Proxomitron" новые библиотеки?
Или я где-то что-то упустил/ошибся?

PS. Попрежнему актуален вопрос - сейчас кто-нибудь фильтрует https-страницы Проксом с "правильным" сертификатом?

SSL не фильтрую, но выше уже давал ссылку на топик, где оно подробно обсуждалось.

Здесь отмечу только, что вопросы конфликта "браузер vs сертификат" всегда решались добавлением самопального сертификата в "доверенные" у браузера.

Ну а про проблемы Хрома с SSL давно легенды ходят. Не знаю, допилили ли они эту тему.

chAlx писал(а):

SSL не фильтрую, но выше уже давал ссылку на топик, где оно подробно обсуждалось.

Я читал этот и другие топики (может быть не все).
В этом топике только один совет из трех дельный:

Цитата:

Original: https://some.secure.site.com/ New : https..some.secure.site.com/

но не могу его проверить, т.к. Хром не считает эту строку адресом и расценив ее как поисковую фразу начинает искать по ней, а IE, пытаясь видимо сам резолвить адрес, ничего не находит выдавая:

Цитата:

Эта проблема может быть вызвана различными причинами, например: •Потеряно подключение к Интернету. •Этот веб-узел временно недоступен. •Нет доступа к DNS-серверу. •На DNS-сервере не найден адрес для домена этого веб-узла. •Возможно, сделана опечатка в адресе. •Если это безопасный адрес (HTTPS), выберите команду "Сервис", "Свойства обозревателя", "Дополнительно", и проверьте, что протоколы SSL и TLS в секции безопасности включены.

Два других же совета:
1. Удалить файлы для защищенного соединения
2. Снять галку в настройках что бы Прокс пропускал страницы через себя не трогая их
- они как бы не к месту и если и решают какую-то проблему, то явно не ту с которой столкнулся я.

chAlx писал(а):

Здесь отмечу только, что вопросы конфликта "браузер vs сертификат" всегда решались добавлением самопального сертификата в "доверенные" у браузера.

Я выше писал:

makrus писал(а):

У меня есть два сертификата действительные по времени ... Оба установлены в корневые сертификаты, еще один действительный от издателя "Proxomitron" и один старый от издателя "SRL" (выданный тоже для Proxomitron)

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

Цитата:

Браузером Internet Explorer заблокировано отображение контента этого веб-сайта с ошибочным сертификатом безопасности

и есть кнопка "Показать содержимое".
Оба этих момента конечно же мелочи (особенно первый), но разве они не свидетельствуют, что конфликт "браузер vs сертификат" не решился добавлением самопального сертификата в "доверенные" у браузера?
Как мне думается, после добавления сертификата в доверенные никаких предупреждений и блокировок со стороны браузера быть не должно и работа с сайтом должна быть такой же прозрачной как по незащищенному протоколу.
Или же то как у меня сейчас работает IE через Прокс (со всеми покраснениями, предупреждениями и блокировкой с возможностью дозагрузки) - это максимум чего можно добиться в решении конфликта "браузер vs сертификат" ?

Цитата:

Ну а про проблемы Хрома с SSL давно легенды ходят. Не знаю, допилили ли они эту тему.

Хром, как мне кажется, в данном случае не добавляет какие-то свои проблемы к имеющейся, а просто позволяет взглянуть на имеющуюся проблему с другой стороны.
Если IE заработает в "прозрачном режиме", то и с Хромом скорее всего проблем не будет.

makrus писал(а):

Оба этих момента конечно же мелочи (особенно первый), но разве они не свидетельствуют, что конфликт "браузер vs сертификат" не решился добавлением самопального сертификата в "доверенные" у браузера?

Хз: я SSL не фильтрую. По-идее, надо сертификат не корневым добавлять, а серверным.

Цитата:

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

Об этом весьма ёмко написано у автора:

Unfortunately (or perhaps fortunately) these warning are unavoidable
since SSL was intentionally designed to prevent an intermediary from
secretly intercepting your data. Proxomitron *is* intercepting your
data, but under your control.

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

Цитата:

Или же то как у меня сейчас работает IE через Прокс (со всеми покраснениями, предупреждениями и блокировкой с возможностью дозагрузки) - это максимум чего можно добиться в решении конфликта "браузер vs сертификат" ?

Вроде этот конфликт можно обойти, подсовывая браузеру расшифрованный (и отфильтрованный) http-контент вместо https. Т.е. то самое http://https..mail.google.com/
Только вот Гугол это воспринимает как хак и отвечает редиректом:

Код:

SSL cipher TLSv1 RC4-SHA (128 bits) HTTP/1.1 200 OK Refresh: 0;URL=https://mail.google.com/mail/ X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block

Это они так защищают клиента от потенциальных угроз... Но вот этот, например, ресурс вообще без варнингов работает (Прокс вроде бы с этими либами).

Цитата:

Хром, как мне кажется, в данном случае не добавляет какие-то свои проблемы к имеющейся

AFAIK именно добавляет: и так-то много узких мест (сертификаты, библиотеки, настройки), а Хром ещё и по-своему SSL понимает. По-крайней мере, когда приходилось работать с клиентскими SSL-сертификатами, были негативные отзывы именно на Хром: "Не умеет".


По теме я бы предложил поискать какую-нибудь более свежую прослойку для работы с SSL (типа как ntlmaps для NTLM-аутентификации). Всё же за 10 лет веб-безопасность продвинулась, а в Проксе новые криптонавороты уже не реализовать :(

chAlx писал(а):

По-идее, надо сертификат не корневым добавлять, а серверным.

Не подскажете где почитать в чем отличие и как сделать правильно?

chAlx писал(а):

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

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

chAlx писал(а):

Вроде этот конфликт можно обойти, подсовывая браузеру расшифрованный (и отфильтрованный) http-контент вместо https. Т.е. то самое https..mail.google.com/ Только вот Гугол это воспринимает как хак и отвечает редиректом: ... Это они так защищают клиента от потенциальных угроз... Но вот этот , например, ресурс вообще без варнингов работает (Прокс вроде бы с этими либами).

У меня возникли проблемы уже с работой самих браузеров... а тут оказывается еще и не с каждым сайтом такое прокатит

chAlx писал(а):

Цитата: Хром, как мне кажется, в данном случае не добавляет какие-то свои проблемы к имеющейся AFAIK именно добавляет: и так-то много узких мест (сертификаты, библиотеки, настройки), а Хром ещё и по-своему SSL понимает. По-крайней мере, когда приходилось работать с клиентскими SSL-сертификатами, были негативные отзывы именно на Хром: "Не умеет".

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

chAlx писал(а):

Это они так защищают клиента от потенциальных угроз...

и они по своему где-то тоже правы.
Если же с вашей или еще чье-то помощью у меня получится сделать сертификаты Прокса действительно доверенными и IE будет открывать защищенные страницы пропущенные через Прокс без каких-либо сложностей, то этих же проблем не будет и в Хроме, хотя он может и добавит какие-то свои с которыми вы сталкивались и о которых говорите.
А пока, "задача №1" как-то "заставить" браузеры верить Проксу..., если это конечно возможно в принципе в том виде как мне бы хотелось.

chAlx писал(а):

По теме я бы предложил поискать какую-нибудь более свежую прослойку для работы с SSL (типа как ntlmaps для NTLM-аутентификации ). Всё же за 10 лет веб-безопасность продвинулась, а в Проксе новые криптонавороты уже не реализовать

Ага, спасибо за мысль. Не хотелось бы "громоздить", но как вариант - вполне может подойти.

makrus писал(а):

chAlx писал(а): По-идее, надо сертификат не корневым добавлять, а серверным. Не подскажете где почитать в чем отличие и как сделать правильно?

Как правильно, сказать сложно. У меня опыт такой: если на сайт повесить самоподписанный серверный сертификат (нормальный по параметрам: с валидным сроком, соответствующий этому сайту и т.п.), то при первом заходе на такой сайт браузер спрашивает, верить ли ему, и предлагает сохранить серт в доверенных. И всё это тестилось на движке Gecko (Seamonkey, Firefox etc).

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

Читать где обычно: в Википедии и Гугле. Есть ещё несколько персонажей, которые на практике занимались фильтрацией HTTPS в Проксе, но пользуются ли этим поныне и где их ловить -- не знаю. Один из них WRFan (бывал и тут, и на РуБорде).

Цитата:

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

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

http://www.sendspace.com/file/9oa8pz

У кого еще не работает безопасное?

У меня заработало нормально. В смысле, фильтрует, но постоянно окна какие-то выскакивают с предупреждениями о подмене сертификата.

В «Опере» фильтрует https нормально. Но окна лезут. Сейчас ищу, как отключить их.

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

http://proxomitron.ru/board/viewtopic.php?p=8311

Тут нашел сейчас тему такую. Можно переделать безопасное в небезопасное.

Сейчас буду пробовать для всех сайтов.

Могут быть проблемы со скриптами из-за 'https..': javascript:alert(location.hostname)

Да, труба настоящая этот https. Как ни возьмись, все барахло получается. Окна замучили.

Есть ProxHTTPSProxy, чтобы это исправить — на форуме другом обсуждается.

Скачал я тоже, но не представляю, как приделать. Там внятно не написано.

А пока только ошибок нарожала мне.

Такие дела.

Рано обрадовался с этим ProxHTTPSProxy: хотя и тащит, но фильтры кривые какие-то.

Https так им и остается.

Надо изучать еще.

Ну, хотя бы работает вообще.

Добавление: Хотя, нет. Сейчас перезапустил — зарботало. Https перехватывает, само шифрует, в проксомитрон сует уже обычное, нешифрованное.

Пока работает это, только если через него все вообще пропускать, нажав «Use Remote Proxy», а иначе не получается только https на него отослать через $SETPROXY в заголовках — что-то ступил. Буду изучать.

http://prxbx.com/forums/showthread.php?tid=1618

Тут вот про него.