No HTTP protocols in Captured Scan

http

asked 2020-02-02 18:34:34 +0000

awp05985
1 ●1 ●2 ●1

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.

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2020-02-02 22:10:28 +0000

kaos
13 ●1 ●5 ●6

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

edit flag offensive 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 ( 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 ( 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 ( 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 ( 2020-02-03 11:09:58 +0000 )edit

add a comment

answered 2020-02-02 18:52:24 +0000

Guy Harris
19890 ●3 ●659 ●207

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.

edit flag offensive delete link

add a comment

Your Answer

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

Add Answer

No HTTP protocols in Captured Scan

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

No HTTP protocols in Captured Scan edit

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

No HTTP protocols in Captured Scan