First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

No HTTP protocols in Captured Scan

  • retag add tags

Details: Brand New download of wireshark 3.2.1. All default settings. Running a live capture no filters of web traffic results in only TCP packets captured. NO HTTP packets are present.

Reading through the numerous other posts from users experiencing this same issue shows that this is a problem which is not being addressed. So far i have read over 10 lackluster responses where this issue is completely neglected. I would upload a file, would this site even allow me to. So let me describe what i see.

I have a capture over 4 seconds. Navigating to ESPN.com. I can see the handshake with espn.com EVERY PACKET from then on forward is TCP or TLS. I see no HTTP packets whatsoever, and again this is all default settings.

My question is how do i get wireshark to recognize HTTP traffic. for a third time, this is all default settings.

awp05985's avatar
1
awp05985
asked 2020-02-02 18:34:34 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

2 Answers

0

The packets shown as TCP are probably ACK-only TCP packets.

The packets shown as TLS are probably not being decrypted by Wireshark. As they appear on the network (Wireshark, like other sniffers, captures raw network traffic), they don't look like HTTP, they look like random values, and that's a feature - the whole point of TLS is to make it hard for people to use sniffers to see the HTTP traffic! (Remember, if it's easy for you to see your credit card number when buying something over the Internet, because you can see the HTTP traffic, it's easy for somebody else to see it as well.)

You might be able to get Wireshark to decrypt the traffic, if you can give Wireshark information it needs to decrypt it (which means it's information you need to get some way other than packet capture, so that only you - and the server to which you're communicating - can decrypt it). See the notes on TLS decryption in the Wireshark Wiki.

Guy Harris's avatar
19.9k
Guy Harris
answered 2020-02-02 18:52:24 +0000
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments
0

most of large modern web sites switched from plain HTTP to HTTPS during last years, there are not many web sites which still use HTTP. Additionally browsers "remember" that the web site is HTTPS-only and even if you type "espn.com" in the address bar your browser requests https://espn.com directly

There are different ways to see plain HTTP, one of them is TLS decryption mentioned by Guy Harris

kaos's avatar
13
kaos
answered 2020-02-02 22:10:28 +0000
edit flag offensive 0 remove flag delete link

Comments

I guess my fundamental question comes down to the get request. I'm fine with wireshark translating packets as tls, but it's the in between packets I do not understand why it doesn't show. I should see an http get request being sent out before the tls handshake initiates, right?

Ultimately this has made analyzing website connections far more tedious. I can no longer simply filter on http and see all the get requests and then follow the conversation of interest.

awp05985's avatar awp05985 (2020-02-03 02:46:05 +0000) edit

I should see an http get request being sent out before the tls handshake initiates, right?

Not if, as @kaos said, "browsers "remember" that the web site is HTTPS-only and even if you type "espn.com" in the address bar your browser requests https://espn.com directly". In that case, the first GET request would go out over TLS rather than directly over TCP.

If the browser doesn't do that - the browser I just trieddoesn't do that - yes, an attempt to fetch http://espn.com will be sent out as HTTP-over-TCP to port 80, and the response will be a "301 Moved Permanently" with the new URL being https://www.espn.com/.

Ultimately this has made analyzing website connections far more tedious.

The goal of HTTP-over-SSL/TLS was to make it more difficult to look at HTTP traffic! People trying to figure out what's going on ... (more)

Guy Harris's avatar Guy Harris (2020-02-03 03:38:48 +0000) edit

And to complete @kaos' last sentence, other ways include, for example, HTTP proxies such as Charles and Fiddler.

Guy Harris's avatar Guy Harris (2020-02-03 03:46:10 +0000) edit

Thank you both for the clarification. Hopefully this new behavior will be updated in the most recent versions of the wcna study guide. Trying to perform functions described in chapter 23 to little avail

awp05985's avatar awp05985 (2020-02-03 11:09:58 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer