1

In my organization we have a cloud proxy that work on a loopback address. The vendor of this proxy has deployed an app on our machine which listens on the loopback address.

Screenshot of LAN settings.

I have captured the apps traffic with Wireshark. You can see it below:

Screenshot of captured traffic from the app in Wireshark.

Also, I have captured traffic on the wifi interface or adapter as well, which is the actual interface of my laptop. You can see the capture below:

Screenshot of captured wifi traffic in Wireshark.

On the wifi interface, I can see that there is an "HTTP connect" packet which is being sent which is totally fine as its proxy devices and I expect that but the problem is that I am not able to see the client hello and server hello or any other SSL handshake packet. So I want to know where these packets are gone, although it is an encrypted traffic.

Also, just additional information: This app create an unencrypted HTTP micro tunnel to their server or cloud(proxy) and in these micro tunnels the traffic is being sent but how my Facebook (which is an encrypted traffic being sent without SSL packets although my application is creating an SSL handshake packets and these micro tunnels are being created for every session)

Improve this question
  • Hard to tell what is going on without having the pcap's. But my guess is that it is purely a display issue, i.e. that you have not enabled wireshark to treat the traffic on this port as TLS and thus it will not display it as TLS. – Steffen Ullrich Sep 4 '19 at 16:03
  • Kindly let me know how i can enable the setting on Wireshark also if you want i will provide you the pacaps. – Shashank Kumar Sep 4 '19 at 16:14
  • 1
    In the menu of current Wireshark version use Analyze | Decode As and add an entry for the port (443) and the protocol you want to use for decoding (SSL). If this does not work please provide the pcap in question as download. – Steffen Ullrich Sep 4 '19 at 16:19
  • It looks like that wireshark will not decrypt TLS inside a HTTP tunnel on port 443 since it thinks that port 443 should be plain TLS (and adds the relevant warnings). I did not find a way to change this behavior so far. – Steffen Ullrich Sep 4 '19 at 18:33
  • So Steffen if I get you correct you mean to say that all ssl handshake packets are there it just HTTP header present on top of these packets and thats the reason we are not abe to see the SSL handshake. – Shashank Kumar Sep 4 '19 at 18:46
1

The "misbehaving" pcap has a capture for HTTP proxy traffic on port 443, i.e. a HTTPS traffic prefixed by a HTTP CONNECT request and response. Port 443 is reserved for direct HTTPS though and not for proxied HTTPS.

It looks like Wireshark somehow insists that it should be either direct HTTPS on this port (which is how the port is commonly used) or that it should have nothing to do with SSL at all. Thus it will detect the HTTP proxy request and response but will then refuse to decode the rest as SSL even if explicitly specified in the settings. I did not find a way to change this behavior.

If one rewrites port 443 in the pcap to something else (like 4433) using tcprewrite the problem magically vanishes and it will happily show the SSL protocol details. Thus, it is all because of some strange behavior of Wireshark and is not a problem of the data itself.

Improve this answer
0

I've seen the exact same problem with the latest versions of Wireshark (it works on older versions). A temporary work around I found is to "Decode As" HTTP on the TCP source port, in your case 55655. TLS info should then be displayed as expected.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.