Hello, I'm trying to decrypt WSS (websocket secure) traffic in in Wireshark, but for some reason I cannot make it work. Here are the steps I followed:
Any idea why that is? Thanks a lot in advance, Antonis Tsakiridis asked 30 Jun '17, 05:53  atsakiridis showing 5 of 7 show 2 more comments |
One Answer:
I think you're out of luck. The TLS connection is using TLS session resumption as the Client Hello provides a Session ID which the server echo's back indicating that the server has retained state for that particular Session ID so no server certificate is required. As the capture does not include the original TLS session that created that Session ID Wireshark (currently) fails to decrypt the session. You capture also seems to contain a lot of duplicate messages which I eliminated using answered 05 Jul '17, 08:27  grahamb ♦ You 're right; seems that the browser even after refresh sometimes remembers previous session IDs and reuses them, which explains why Cert wasn't sent by server in ServerHello and wireshark couldn't correlate. I verified by using Firefox (instead of Chrome) and a private tab and indeed first WSS connection has full negotiation, and in that case indeed decryption for WSS worked like a charm! I had another error in the RSA keys list configuration, where I used 'tcp' instead of 'http', but after I fixed that all was good :) The only issue I'd like to improve now is the presentation where I have the following issues. I'm working on an open source communications platform, and we 're dealing a lot with SIP. In fact the WSS traffic I'm investigating contains SIP flows. So I'd like instead of getting the generic Websocket presentation in the packet list as can be seen here: https://drive.google.com/file/d/0BwfD74mG87iMcWNmTFQ0RTk1bDA/view, to see that its a SIP message and its type (i.e. REGISTER) like this: https://drive.google.com/file/d/0BwfD74mG87iMTDRRbGxVbHE5RUE/view (taken from non WSS session where SIP is directly on top of TCP and hence is presented nicely). Do you think that is possible with the current state of Wireshark, with some additional configuration? If not I could try to contribute it, with some help from you guys. I think it will prove pretty useful for a lot of folks out there, as WS is pretty much used everywhere nowadays for signaling in communication systems (and with WebRTC boom it's even more widespread). Notice that the same issue exists when working with non encrypted WS. It's still not parsed as SIP and it's harder to do troubleshooting Finally thanks for the pointer on editcap. Actually I had tried it on another pcap on my Mac but I got:
So I didn't try again. Maybe because I'm collecting using tcpdump and Ctrl-C to stop? Could it be that a packet is cut in half and it messes up the parsing Thanks a lot for your quick responses and help. I know first hand that keeping up with community requests can be hard. (06 Jul '17, 03:17) atsakiridis @grahamb, I just posted a comment here and then edited it again to make a small change but got an error in the lines of: 'Akismet thinks your comment is spam' and I lost it! Can you guys check where that comment went and try to repost it -it was huge and will take me forever to rewrite :( (06 Jul '17, 03:21) atsakiridis
Nope. Ctrl-C stops tcpdump gracefully, the last packet is written in full. "Cut in the middle" packets happen when you copy the output file before stopping tcpdump as the file write buffering ignores packet borders. To double-check you can export just a few packets from the beginning of the capture and try editcap on the exported file. (06 Jul '17, 03:31) sindy @atsakiridis If there is a (06 Jul '17, 03:50) Lekensteyn Second option works perfectly, thanks! We will also consider introducing the SIP header you 're talking about for easier troubleshooting (06 Jul '17, 03:59) atsakiridis @sindy, here's what I tried: I opened the pcap and did 'Export Specific Packets' without applying any filters. And then tried to editcap the result of that export and it worked fine. So there seems to have been something wrong to the original capture from tcpdump that somehow was 'corrected' by the export. But can't say what. I did verify that the number of frames between original and exported was the same though. (06 Jul '17, 04:41) atsakiridis ...while the original file opens normally in Wireshark but still causes trouble to editcap? If so, may I see that file? (06 Jul '17, 04:43) sindy @sindy unfortunately I cannot share the problematic pcap as it contains sensitive data, and trying to reproduce the issue now is not possible. I'll keep an eye on it and if it happens again in the future will post again here to get to the bottom of this. Thanks for the help (06 Jul '17, 04:55) atsakiridis showing 5 of 8 show 3 more comments |
What Wireshark version is in use? Latest stable is 2.2.7. Are you sure that the private key matches the one in the certificate? In the debug file you should see a match between the pubkey from the Certificate handshake message and the pubkey from the private key (if you use Wireshark >= 2.0).
Thanks for the prompt reply Lekensteyn. So let me try to answer your questions: a. Used 2.2.3, but updated to 2.2.7 to make sure it's not an issue with previous version. The problem is that the issue still occurs :(. b. I did some more digging after you mentioned pubkey in the debug file and I realized that there is no Certificate in the ServerHello in the .pcap! Is this somehow legit? I then checked the SSL debug file more information and I saw only this:
dissect_ssl enter frame #346 (first time) packet_from_server: is from server - TRUE conversation = 0x116b9fbb0, ssl_session = 0x116ba0fd0 record: offset = 0, reported_length_remaining = 86 ssl_try_set_version found version 0x0303 -> state 0x91 dissect_ssl3_record: content_type 22 Handshake Calculating hash with offset 5 81 decrypt_ssl3_record: app_data len 81, ssl state 0x91 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 ssl_try_set_version found version 0x0303 -> state 0x91 ssl_dissect_hnd_hello_common found SERVER RANDOM -> state 0x93 ssl_dissect_hnd_srv_hello found CIPHER 0x002F TLS_RSA_WITH_AES_128_CBC_SHA -> state 0x97Any hints?
Also, here's another, successful scenario where I use plain TLS (i.e. not WSS). The ServerHello has a Certificate and this is how it look in SSL debug (notice the additional fields on the bottom):
dissect_ssl enter frame #320 (first time) packet_from_server: is from server - TRUE conversation = 0x12166b840, ssl_session = 0x12166c420 record: offset = 0, reported_length_remaining = 821 ssl_try_set_version found version 0x0301 -> state 0x91 dissect_ssl3_record: content_type 22 Handshake Calculating hash with offset 5 816 decrypt_ssl3_record: app_data len 816, ssl state 0x91 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 821 ssl_try_set_version found version 0x0301 -> state 0x91 ssl_dissect_hnd_hello_common found SERVER RANDOM -> state 0x93 ssl_dissect_hnd_srv_hello found CIPHER 0x002F TLS_RSA_WITH_AES_128_CBC_SHA -> state 0x97 dissect_ssl3_handshake iteration 0 type 11 offset 86 length 727 bytes, remaining 821 lookup(KeyID)[20]: | ea 6b 53 25 49 89 f8 29 a7 11 fd 9f 2f 97 88 6a |.kS%I..)..../..j| | fd 8f 24 5b |..$[ | ssl_find_private_key_by_pubkey: lookup result: 0x7fc814867400 dissect_ssl3_handshake iteration 0 type 14 offset 817 length 0 bytes, remaining 821One totally irrelevant hint is to use < code > < /code > markers around your log output so that it shows up in a readable format.
Thanks a lot grahamb for fixing this! I'm new to this forum, so will keep it in mind from now on
Any chance of a capture along with the key so others can test?
Hello, sure, I'm sharing a link from my google drive that points to wireshark-wss.zip which contains: 1. wss.pcap which is the actual capture file, notice that WSS traffic is towards/from port 5083, 2. server.key which is the WSS server private key (it's a just a test key), 3. ssl-debug-wss.log which is the wireshark SSL debug file that I told you about. Here it is: https://drive.google.com/file/d/0BwfD74mG87iMQ3MxblNvOTA0Nm8/view?usp=sharing
As an example you can check frame #49, which is the ServerHello that doesn't include a Certificate section at all
Any hints on what might be wrong?
In case you 're interested, this is the RSA keys list file contents:
"any","5083","tcp","/Users/antonis/Documents/server.key",""
Best regards and thanks in advance, Antonis