How to decode the packet which is decrypted SSL in wireshark? - wireshark

everyone. I am working a MQTT connection by using TLSv1.2 with the server.
Before asking the question, I've spend sometime to googling the answer. But all the answers I found are talking about how to decrypt SSL trafic in wireshark. This part is done successfully. My question is , after I successfully decrypted the data by setting the CLIENT RANDOM and MASTER SECRET in a file and set it up in TLS deocoding settings in Wireshark, how to decode the decrypted data?
For all decoded data, Wireshark show as seperated tab named as "Decrypted TLS". Once I click the tab, it only shows the raw data as HEX.
Can I ask Wireshark to further decode the raw data by using known protocol such as MQTT?

Related

Wireshark/QUIC - Cannot decrypt QUIC

I'm trying to view the payload of QUIC packets although, with no luck. I can decrypt fine TLS packets using SSLLOGFILE file that generated by the browser and load it to Wireshark, I can see HTTPS and DoH and almost all TLS encrypted packets are decrypted correctly.
With QUIC this isnt the case, I can across this post: https://bugs.chromium.org/p/chromium/issues/detail?id=1101691
And there they said that the problem with SSLKEYLOGFILE exporting keys for quic with chrome has been fixed in chrome 89, so I've downloaded chrome 90 (chrome dev version) but still no luck.
Any Ideas what i'm doing wrong?
I can see QUIC packets, can see the client hello and all of the unencrypted QUIC packets are parsed correctly in wireshark, but still no decryption.
Are you using a sufficiently recent version of WireShark? See https://github.com/quicwg/base-drafts/wiki/Tools for details.
Which QUIC version are you trying to decode?
With Chrome 88.0.4324.192 and Wireshark 3.5.0rc0-788 i can succesfully capture and decrypt a quic draft-29 ("h3-29") session.

IoT Edge Offline Data Storage decoding .log data file

I have mounted local storage to my Edge Hub/Agent Modules, and when the device goes offline it stores the data locally. In the event that the device cant go up online, I need to be able to read the offline data and send it to IoT hub. After looking at the file, some portion of the message is base64 encoded, and some parts have non-base64 encoded characters.
Is there a method for decoding the message or any architecture patterns to support cases when a device can't go back up online and upload the data?

Decrypt Wi-Fi packet of SSID which contain colons

I am trying to decrypt an IEEe802.11 packets on Wireshark.
Manual showed that adding "wpa-pwd" "mypassword:myssid" will do the work but the thing is ssid contain colons and it doesn't work properly.
For example, password is "12345678" and ssid is "MyAP:12:34:56" then how can I decrypt the packets?
I have tried
12345678:MyAp:12:34:56 but it never worked ...

How can I determine which packet in Wireshark corresponds to what I sent via Postman?

I'm trying to figure out why REST calls sent from my handheld device (Windows CE / Compact Framework) are not making it to my server app (regular, full-fledged .NET app running on my PC).
The handheld device and the PC are connected - I know that because I can see the handheld device in the PC's Windows Explorer, Windows Mobile Device Center verifies the connection between the two is valid, etc.
I reach the breakpoint on my server app running on my PC when I pass the same REST call via Postman, namely:
http://192.168.125.50:21609/api/inventory/sendXML/duckbill/platypus/poisontoe
...but not when calling the same from the handheld device.
So, I want to see in wireshark just what is being sent from postman, so I can see what to look for when attempting to call the same REST method from the handheld device.
I set up a filter in wireshark, namely "ip.dst == 192.168.125.50" and get a handful of results when calling the method via Postman, but nowhere do I see "port 21609" which I would expect to. If I saw this, I would know I was looking at the right packet, but...where is it? When I run Postman and make the call, there are four packets captured by Wireshark, and none of them give that as the port number in the "User Datagram Protocol" element.
If the port number is disregarded, how can I determine which packet is the one from Postman?
UPDATE
Yoel had a good idea; I added "Dest port (unresolved)" and "Sourceport" as columns to display.
I then started a new live capture in Wireshark and sent the URL / REST method from Postman.
The breakpoint in the server app was indeed hit. I F5'd through it, and stopped the Wireshark capture.
"21609" is not seen in the Dest Port column anywhere.
Why? How is the URL being sent, and yet Wireshark is not detecting the port to which it was directed?
Also, in the Protocol column in Wireshark, I see no "HTTP" entries.
To see the destination port in the packet list, you have to add a column by right clicking in a column header and selecting Column preferences.... Then click on the + sign, choose a column title, and put
tcp.dstport
as the Fields parameter.
You can also directly use the display filter with the expression:
tcp.dstport == 21609
(tested with Wireshark 2.2.0)
The answer is as short as:
tcp.port==53218
First that the new postman port is 53218, second the original Answer is tracking only the requests without the responses. So if you want to track the whole communication - tcp.port==53218 will do it.

Real-time Transport Protocol is not used in youtube?

I came across reading about real time protocol in Wikipedia, which mentions the following :
"RTP is used extensively in communication and entertainment systems that involve streaming media"
I was curious about this protocol and wanted to see this in wireshark. I thought youtube.com might be using RTP when running videos, but was surprised to see that only TCP packets are being sent when a video is being played.
Can someone please tell another free website which implements RTP, so that I will be able to see it in wireshark. (I am actually wanting to explore network optimization opportunity in my server applications by using RTP, since it is ok to loose a few packets)
According to Computer Networks, RTP is the payload of UDP (or TCP) as the book indicates.
Here is a picture from the book:
According to WireShark's wiki, only RTP on UDP could be detected by WireShark. (Thanks to Ralf)
Youtube uses HTTP AFAIK. Also, keep in mind that RTP can be sent over UDP as well as TCP.
An RTSP server can be used to start an RTP media session. I don't know any public servers, but another option would be to download the live555 RTSP server. There are also some example media files. Then all you need to do is build the media server application as well as the openRTSP client and use the client app to connect to the server for the stream. The client can request RTP over UDP, TCP, etc.
Alternatively you could also use Darwin Streaming Server as an RTSP server.

Resources