HTTP Debugging Proxy или зачем нужны подписи в HTTPS

Иногда, в целях изучения поведения сайта, нужно узнать, какие страницы открывает браузер, что отправляют и получают скрипты с использованием AJAX, с каких сайтов грузится множество ненужных картинок и скриптов. Узнать почему ваши скрипты не отправляют ту информацию, которую вы хотели запрограммировать.
В этом нам могут помочь различные средства. Например плагин firebug в Mozilla FF прекрасно справится с большинством задач.
Но если нужно отследить именно потоки запросов — ответов, то удобней будет воспользоваться специальной утилитой.

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

Пароли, как и другие данные формы, как правило передаются незашифрованными внутри установленного соединения, и вы можете отследить пароли передаваемые со своего компьютера или с компьютера к которому получен доступ. Необходимо понимать, что подобные программы могут быть запущены на промежуточном сетевом оборудовании или ваш компьютер может быть перенастроен так, чтобы трафик с него шел другим путем.
А теперь вопрос: а что будет, если шифрование выполняется на уровне соединения, например используется протокол HTTPS?
HTTPS работает поверх SSL, предусматривающего, следующую процедуру выбора ключа.

  1. Владелец web-узла генерирует ключи (открытый и закрытый). Открытый подписывается в центре сертификации. А подпись центра сертификации должна быть установлена в вашем браузере.
  2. Клиент устанавливает связь по специальному порту (HTTPS — 443);
  3. Сервер высылает клиенту сертифицированный открытый ключ;
  4. Клиент проверяет подпись на сертификате, используя открытый ключ Центра сертификации;
  5. Клиент выбирает сеансовый ключ, шифрует его открытым ключем сервера и отправляет результат на сервер;
  6. Сервер расшифровывает сеансовый ключ своим закрытым ключем;
  7. Устанавливается соединение с помощью сеансового ключа.

Если открытый ключ сервера не подписан в Центре сертификации, или информация об этом центре отсутствует в браузере, то клиенту будет выдано предупреждение о том, что узел является непроверенным.

Итак. Как прокси может читать данные HTTPS соединений?
Используя известную криптографическую атаку типа «Человек посередине» (этим человеком будет прокси сервер).

  1. Клинт отправляет прокси запрос на соединение;
  2. Прокси устанавливает защищенное соединение с сервером (по описанному выше алгоритму);
  3. Прокси отправляет клиенту свой открытый ключ, который якобы сгенерирован для сервера.
  4. Клиент не может проверить этот ключ. Браузер выдает соответствующее сообщение с вариантами принять или отклонить.

Таким образом, HTTPS соединение может быть установленно так, чтобы на прокси могли быть прочитаны все данные. Но при этом клинт будет предупрежден, о том, что данному соединению нельзя доверять.

Если сертификат никому не известной закрытой сисстемы не может быть проверен — то возможно он никогда и не был подписан в ЦС.
Если же не может быть проверен сертификат некоторой платежной системы — его наверняка нужно отклонить и поискать дыры в вашем интернет соединении.

  • Василий Стрелков

    Подскажите чем отличаются между собой SOCKS прокси от HTTPS- мне для программы они требуются, но их так мало бесплатных можно найти. Хочу купить доступ к сервису https://kupit-proxy.ru/ он нормальный, не знаете?