I'm learning about sniffing packets in Wireshark. When I enter the password of my wifi and I can start seeing a lot of traffics and I realize that they are all decrypted. But I don't know how these packets are decrypted because different clients have different PTKs and counter mode in ccmp.
For example, I perform a simple MITM between my phone and the router. I think that the HTTP packet that sending from my phone must be encrypted with its AES-CCMP(PTK) at the data link layer but somehow I can capture password from a simple HTTP authorization page through GET request. So how can Wireshark do that?
Sorry for late answer.
HTTP protocol by itself does not support encryption, this means content of the packet can be seen in plain text. For example, webpage http://icanhazip.com uses HTTP protocol, so if you run Wireshark and head over to this website, you can see IP responded by the webpage in the wireshark's "follow TCP stream" window. I run this scenario and posted its picture.
Not all of the pages are on HTTP, and the majority of the websites, nowadays, use HTTPS. HTTPS is HTTP which send its packets with TLS protocol. TLS is responsible for encrypting and sending the HTTP packet. So if you sniff traffic of a website that uses HTTPS, you can't see the content of the request and response. For example, run Wireshark and go to https://icanhazip.com. Here is a picture of it.
In your case, because web page you are visiting (I think you are visiting this page)
uses HTTP and not HTTPS, the content of the packets can be seen in the Wireshark, even vital things like authorization information.
Related
I understand that HTTP is a protocol that allows information to be transferred between a client and a server. At the moment, this protocol is used everywhere: when we're opening needed web page, downloading music, videos, applications...
MDN
HTTP is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is reconstructed from the different sub-documents fetched, for instance, text, layout description, images, videos, scripts, and more.
But it's not entirely clear to me what exactly HTTP does during this information transfer. If, as I read, a protocol is essentially a set of rules, then does it mean that HTTP just setting up rules for passing information between server and client? If so, what are these rules and what are they for?
Hypertext Transfer Protocol is a communications protocol. It is used to send and receive webpages and files on the internet. It is now coordinated by the W3C. HTTP version 1.1 is the most common used.
HTTP works by using a user agent to connect to a server. The user agent could be a web browser or spider. The server must be located using a URL or URI. This always contains http:// at the start. It normally connects to port 80 on a computer.
A more secure version of HTTP is called HTTPS (Hypertext Transfer Protocol Secure). This contains https:// at the beginning of the URL. It encrypts all the information that is sent and received. This can stop malicious users such as hackers from stealing the information and is often used on payment websites. HTTPS uses port 443 for communication instead of port 80.
I recently bought an ip cam for a project. So my project was just to create a button on a webpage to show the video feed coming from the cam when clicked on it. If i have to stream the rtsp link of the ip cam via a browser, i need to use ffmpeg for converting into HLS. But when i use a http video link of the cam, its easy and convenient. So my question is, what advantage does rtsp have over http ? and what method should i choose in a industrial project. At the moment i have successfully implemented the button with http video link and it works. I was just curious to know the advantage i will have if i use rtsp. Thanks a lot for you precious time.
it depends on the network environment that you are dealing with. For sure using dash/HLS will result in higher latency but on the other hand using TCP for streaming is easier to go through the firewalls.
Apple reasoning for introducing RTSP over HTTP:
Using standard RTSP/RTP it is possible to stream a presentation to a user via a single
TCP connection. (See RFC 2036 “Real Time Streaming Protocol (RTSP)”, section 10.12)
Unfortunately, that is not sufficient to reach a significant population of Internet users.
These users are typically on private IP networks where the client machines have indirect
access to the public Internet via email and HTTP Proxies.
The QuickTime HTTP transport exploits the capability of HTTP GET and POST
methods to carry an indefinite amount of data in their reply, and message body
respectively. In the most simple case, the client makes a HTTP GET request to the
streaming server to open the server to client channel. Then the client makes a POST
request to the server to open the client to server channel.
Link
I am new to networking and Wireshark in general, but there's one thing I'm really stuck on.
I opened Wireshark, started sniffing, then I went to different websites both using HTTP and HTTPS.
I stopped the sniffing and tried to filter out "http" and "https" (different tries), but it shows nothing.
In the Protocol column I see only TCP, UPD, DNS, TLSv1 etc. But no HTTP and not HTTPS.
What may cause this?
Thanks
Wireshark cannot see application data because it is encrypted with TLS. That's why Wireshark use TLS and TLS version in protocol column instead of HTTPS.
Almost all big website are using HTTPS todays. When you try to use HTTP the connection will be redirected to HTTPS. There are different redirection methods and it is possible the Wireshark cannot get enough data to know the communication is HTTP or not. That's why you can see TCP in protocol column instead of HTTP.
So You can filter packets with TCP ports:
tcp.port == 80 or tcp.port==443
You can filter the HTTP traffic with the help of Wireshark easily.
Refer : How many http and https connections established in wireshark?
Even you can get the additional information , like source IP, destination IP, flags etc from hex format. Refer Link,
How to obtain the source IP from a Wireshark dump of an HTTP GET request
My question is about networking. I'm just looking for a simple answer, yet I couldn't find one after 1 hour research. I know there are techniques such as Wi-Fi Hotspot, man-in-the-middle-attack, local network, echo switch, etc. But I couldn't find an answer to my specific question.
Let's say, client A wants to communicate with server B, and server B says client A must authenticate himself via HTTP basic authentication first. My question is, what happens if client A sends the authentication credentials via HTTP layer (insecure), who can read the HTTP headers that the client A sends to server B over the internet? Would it be easy to do that? Like placing a breakpoint between two arbitrary routers, which help to transfer the packets across the internet, in order to read those headers? How does it work in general?
Thank you!
PS.: I am not trying to learn and do it. I just want to know, how dangerous it would be, if the HTTP basic auth is made via the insecure HTTP layer.
Who can read the HTTP headers that the client A sends to server B over
the internet?
Your Network Provider (e.g Wi-fi hotspot Provider).
Your Domain Name System server (DNS, as 192.168.1.1).
Your Internet Service Provider (ISP).
Your Virtual Private Network if using one (VPN server).
Yourself Or a Virus.
and here comes the HTTPS (HTTP + SSL Encryption)
SSL is about communicating in a language that you and the server only understand.
How dangerous it would be if the HTTP basic auth is made via the insecure HTTP layer?
Well, from above, You can totally get that a simple virus or even a public Wi-fi Hotspot Device can capture and see all of your data if the communication was done in a plain HTTP Socket.
A Simple packet may contain all of your Device information including its basic contents as your passwords, credit cards information, The HTML form for the signup/login that you've just completed with all its data, VoIP Calls and messages being sent to the server + upcoming/received ones.
that's why we need SSL encryption and the server should have a valid SSL certificate too.
By the way, your device may have sent thousands of packets while you read this now!
Capturing the packets that your device sends or even the packets that other devices on your network send can be done through any packet capturing tool or software as Wireshark.
I am having an issue with Server Sent events.
My endpoint is not available on mobile 3G network.
One observation I have is that a https endpoint like the one below which is available on my mobile network.
https://s-dal5-nss-32.firebaseio.com/s1.json?ns=iot-switch&sse=true
But the same endpoint when proxy passed using an nginx and accessed over http (without ssl) is not available on my mobile network.
http://aws.arpit.me/live/s1.json?ns=iot-switch&sse=true
This is available on my home/office broadband network though. Only creates an issue over my mobile 3g network.
Any ideas what might be going on?
I read that mobile networks use broken transparent proxies that might be causing this. But this is over HTTP.
Any help would be appreciated.
I suspect the mobile network is forcing use of an HTTP proxy that tries to buffer files before forwarding them to the browser. Buffering will make SSE messages wait in the buffer.
With SSE there are a few tricks to work around such proxies:
Close the connection on the server after sending a message. Proxies will observe end of the "file" and forward all messages they've buffered.
This will be equivalent to long polling, so it's not optimal. To avoid reducing performance for all clients you could do it only if you detect it's necessary, e.g. when a client connects always send a welcome message. The client should expect that message and if the message doesn't arrive soon enough report the problem via an AJAX request to the server.
Send between 4 and 16KB of data in SSE comments before or after a message. Some proxies have limited-size buffers, and this will overflow the buffer forcing messages out.
Use HTTPS. This bypasses all 3rd party proxies. It's the best solution if you can use HTTPS.