Если я использую этот фильтр в Wireshark: http.request.method == "POST" и используйте кнопки голосования, чтобы проголосовать за вопрос об обмене стеком, затем Wireshark перехватит соответствующий запрос POST. Я также вижу в отладчике Chromes, что запрос является POST.
Однако на другом сайте, который я пытаюсь изучить, когда я нажимаю кнопку формы, которая запускает POST (и отладчик Chromes подтверждает, что это POST), Wireshark ничего не фиксирует.
Почему это могло быть?
Редактировать:
Спасибо за все советы. В конечном итоге мне удалось проверить POST, отправленный с моего веб-сервера с помощью Fiddler, и это действительно помогло мне. Я не упоминал об этом, но мой веб-сервер - это Jetty, работающий локально в Ubuntu, и я использую Apache HttpClient для обработки запросов. Для Java, если вы не используете HttpClient, этот вопрос полезно. Если да, то проверьте этот вопрос вне.
В любом случае Fiddler по-прежнему необходимо настроить для мониторинга HTTPS-соединений, отметив опцию в Tools -> Fiddler Options -> HTTPS -> Capture HTTPS CONNECTs.
HTTPS шифрует содержимое сообщения от любого, кто следит за проводом - это именно то, что вы делаете, - поэтому оно работает, как задумано. Любой, кто выполняет захват пакетов где-либо между браузером и веб-сервером, просто видит зашифрованный трафик.
Wireshark - не лучший инструмент для анализа HTTPS-трафика. Для этого вы можете использовать отладчик, встроенный в браузер, или что-то вроде Скрипач, который работает на вашем компьютере как прокси-сервер и расшифровывает HTTPS-трафик.
Fiddler делает это, сидя посередине - веб-сервер ведет HTTPS-диалог со Fiddler, а ваш браузер ведет HTTPS-диалог с Fiddler. Но Fiddler может расшифровать оба соединения. Это, конечно, вызовет пугающие предупреждения о недействительности сертификата, если вы не добавите сертификат CA Fiddler в свой браузер / ОС.
Wireshark БУДЕТ работать, если у вас есть файл закрытого ключа SSL. Итак, если вы находитесь на стороне веб-сервера, загрузите свой закрытый ключ SSL в Wireshark и он расшифрует трафик за вас. Это работает, только если у вас есть доступ к закрытому ключу - вы не сможете расшифровать трафик в / из stackexchange таким образом, но вы можете использовать его для веб-серверов, которыми вы управляете.
Теперь, когда вы выяснили, что трафик идет от вашего веб-сервера к третьему лицу, у меня для вас есть другой вариант, если вы используете Linux или Mac: митмпрокси
Либо скрипач, либо mitmproxy должны быть в состоянии сделать за вас расшифровку посредника. Сложная часть - заставить данные проходить через прокси. В Linux это относительно просто использовать iptables - mitmproxy дает инструкции по установке для этого. Как в Windows, так и в Linux вы должны иметь возможность использовать Apache mod_proxy ProxyRemote настройки для направления трафика на ваш прокси-сервер.
Это мощь потому что другая сторона использует HTTPS.