Ask Your Question

SSL/TLS packets for 302/redirects not being captured

asked 2021-09-28 15:29:33 +0000

ohaya gravatar image

updated 2021-09-28 17:17:25 +0000

grahamb gravatar image

I just installed Wireshark 3.4.8, and am trying to trying to diagnose a problem with requests that are going to a URL that is protected by an Oracle OAM webgate, where the request is being made from a webpage that contains Javascript and XMLHttpRequest code. The initial request is going through a CORS proxy ("CORS Anywhere") that I host locally.

For requests that go to OAM-protected URLs, the OAM webgate causes several 302/redirects, and I am using Wireshark to try to capture that information. The initial flow looks like:

1) Browser+Javascript+XHR =====> protected URL (this is non-SSL)

2) OAM webgate sends 302/redirect response =====> browser (the "location:" response header is something like "https://access....", i.e., the 302/redirect is TO a different SSL-enabled URL.

3) In the normal OAM flow, the next 302/redirect is also to an SSL-enabled URL

4) And after that, there are 2 more 302/redirect (so 2 more requests/responses) that are to non-SSL enabled URLs.

In the Wireshark capture, I can see the #2 (the response), but I DON'T SEE any other requests/responses until the final request/response pair, i.e., most of the 302 request/responses appear to be missing from the Wireshark capture.

From the response in the LAST request/response, I can see some response headers that are injected by the CORS Anywhere proxy:

 [truncated]X-CORS-Redirect-1: 302
 [truncated]X-CORS-Redirect-2: 302



Those "X-CORS-Redirect-1" and "X-CORS-Redirect-2" headers, and the "x-final-url" header are added to the response by the CORS Anywhere, for debugging purposes, and that SEEMS to indicate that there WERE those requests, BUT the actual requests don't seem to be captured by Wireshark, for some reason.

I had suspected that those 2 request/responses might not have been captured because those URLs were SSL-enabled, so I configured Wireshark with the server private key, but even after that, I still am not seeing the actual re-directed requests/responses.

FYI, in Wireshark I have been using "http||tls" as the filter...

Can anyone suggest what I need to do in order to get Wireshark to either capture those missing 302 request/responses, or to make them visible in Wireshark?

Sorry for the longish post :(!!

Thanks, Jim

edit retag flag offensive close merge delete


As I was thinking about the last comment to Andre below, I realized that I had not mentioned one, possibly important, piece of information:

The machines that I am working/testing on are on Amazon AWS. The thing is with AWS is that, I believe that the network adapters don't operate in promiscuous mode.

That is probably why when I ran the tcpdump on the other machine (per comment below) I was seeing one of the 302 request/response pairs in tcpdump, but I wasn't able to see that 302 request/response pair in Wireshark on my "workstation" machine.

Has anyone been able get around that AWS limitation?

Thanks, Jim

ohaya gravatar imageohaya ( 2021-09-29 03:33:50 +0000 )edit

I don't think you are supposed to be able to do that. It would break stuff for the hosting party. Networking inside clouds is rather different. And it coukld break things if anyone could put machines in promicious mode.

So in a cloud setup all traffic you can see is what goes to your machine Which also makes it some times harder to troubleshoot there because some machines in the cloud can't capture themselves at all..

hugo.vanderkooij gravatar imagehugo.vanderkooij ( 2021-09-30 07:11:33 +0000 )edit


As I mentioned in the part of the thread with Andre below, I started building a new environment using VirtualBox, and I have it almost done/working.

I setup most of the machines, including 2 apaches (one to host the page with the javascript and the other to host the "target" URL for the Javascript/XHR. I also have a Windows machine in a VM and I have Wireshark installed on that machine, and I have the adapter on that machine set to Promiscuous, and I use the browser on that same machine. So the overall configuration is th same as what I had on AWS.

I have not added in the OAM webgate/protection yet, but I was testing with the Apaches and some preliminary test setup using mod_alias/Redirect directives on the target Apache configuration. This is also still only non-SSL so far, but when I test ...(more)

ohaya gravatar imageohaya ( 2021-09-30 13:34:36 +0000 )edit

BTW, off-topic, but how can I format text in comments in "add comment"? It seems to just glom all of the text together so the formatting is really hard to read???

ohaya gravatar imageohaya ( 2021-09-30 13:36:00 +0000 )edit

how can I format text in comments in "add comment"?

The formatting for a comment is (almost) the same as for an answer so I sometimes use the answer block as a preview for a comment :-).

André gravatar imageAndré ( 2021-10-06 10:59:45 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2021-09-28 16:47:22 +0000

André gravatar image

To decrypt the TLS traffic you need the (Pre)-Master-Secret.

For example using curl on Bash (Linux) prompt:
SSLKEYLOGFILE=$PWD/mykey.log curl -L http://...
And add this file to wireshark.

For more information see:

The private key can only be used on old/outdated ciphers.

PS: better a long post than one with not enough info :-).

edit flag offensive delete link more


Hi Andre,

Thanks for the information.

When I go to Edit => Preferences => Protocols, there is no "SSL" to choose. Should I be using "TLS" instead?

Also, FYI, per step 8 in that gitlab link, when I use filter "tls and (http or http2)" the text box is still red (I guess it is not a valid filter string?). What should the filter be?

Thanks, Jim

ohaya gravatar imageohaya ( 2021-09-28 19:26:51 +0000 )edit

When I go to Edit => Preferences => Protocols, there is no "SSL" to choose. Should I be using "TLS" instead?

Yes, SSL is the predecessor of TLS. Nowadays think of SSL as an alias for TLS.

when I use filter "tls and (http or http2)" the text box is still red

Probably a typo. When I enter tls and (http or http2) (without the quotes) as a display filter in WS 3.4.8 it goes green (valid).

Note: this filters decrypted https traffic only. For both plain http and decrypted https you can use the filter http or http2 instead.

André gravatar imageAndré ( 2021-09-28 20:45:54 +0000 )edit


Thanks for the clarifications.

I think that I have enabled the SSL decryption now.

However, when I test, I still am having the problem of not seeing the 302/redirects.

Let me try to give a more detailed description of my problem.

1) When I access an OAM-protected URL ( directly using a browser, I see 3 302/redirects, following by a 200/OK.

The first 302/redirect causes a request to "Location:" (i.e., to an SSL URL, configured for client authentication).

When the browser is redirected to that URL, the browser pops up a cert window so allow the user which cert to use for the authentication.

The second 302/redirect causes a request to "Location:" (i.e., a non-SSL URL).

2) When I access the same OAM-protected URL, but ...(more)

ohaya gravatar imageohaya ( 2021-09-29 00:32:58 +0000 )edit


Here is an interesting thing?

Just on a whim, I tried running tcpdump on the server side (the side that is hosting the wavatarget-charlie/index.html page), and when I used Wireshark to read that tcpdump output file, it is showing ONE of the 302 responses to ONE of the GET requests from the client.

The PCAP from the server tcpdump is only showing that request (coming into the server) and response (going from the server back to the client).

The PCAP from the server tcpdump is NOT showing the second request that is caused by the 2nd 302 (coming into the server) nor the corresponding response.

I am not quite sure what to make about all of this, but recall that the request that goes from the client to the server due to the 1st 302 has a request to an SSL URL, whereas the request due the ...(more)

ohaya gravatar imageohaya ( 2021-09-29 01:50:46 +0000 )edit

Another piece of the puzzle is that non-standard TCP ports were used: 7777 and 14430.

To verify if you did capture traffic over these ports use (menu) Statistics / Conversations or Endpoints, or use the display filter tcp.port==7777, etc..

Next you need to configure Wireshark 3.4.8 to recognize https traffic over these ports. Add in the HTTP preferences “SSL/TLS ports” the extra ports “,7777,14430”. (By the way the development version 3.5.0 does recognize this traffic out-of-the-box.)

Wireshark dissects the captured network packets and displays it. For instance the HTTP headers are displayed (after decryption) but it is up to the User-Agent (the browser) what to do with this received information. For the “content-security-policy” HTTP header see . As I read it “nosniff” is invalid. Maybe a mix-up with the (outdated) “X-Content-Type-Options” which tells the browser to stop guessing the content-type.

André gravatar imageAndré ( 2021-09-29 09:50:58 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2021-09-28 15:29:33 +0000

Seen: 520 times

Last updated: Sep 28 '21