0

Why do I still see data passing by when the traffic is encrypted? I use packet capture to intercept the traffic of mobile application within my phone. Sometimes I do see garbage values and sometimes API destination along with garbage values.

  • Please provide some details on your setup (in particular how and where you capture your data - directly on the mobile? on a proxy?) as well as examples of the data you get. – WoJ Jul 31 '16 at 17:33
  • From your question, I think you are actually looking at the actual traffic and it is most normal to see the connection attempts. What is encrypted is the data exchanged which appears to you as garbage values and is perfectly normal. – Julie Pelletier Jul 31 '16 at 17:40
  • @WoJ I'm using Packet Capture. Its an application which provides interception and let you see the traffic. The app has an SSL when I checked it's server. This doesn't show up on intercepting and easily shows me the server destination. I guess the packets sent on the server has some token with garbage format. Applications like snapchat, chrome browser doesn't come with any data as Packet Capture itself shows that that they are SSL traffic. Is it something like misconfigured SSL? – m1lak0 Jul 31 '16 at 18:59
4

Its because the API destination cannot be hidden by SSL. Whats hidden by SSL, is the data, eg the request and response, including the path part of URL.

So out of this url: https://www.example.org/search.php?sdata=somedata the following will be encrypted: /search.php?sdata=somedata the first part, https://www.example.org, will NOT be encrypted (read more why not).

Whats not hidden, is the destination IP and destination port. Furthermore, the DNS request immediately preceding this, is sent in the clear.

A sniffer, can detect the caonical name of the destination in 2 ways:

Either, it can remember previous sniffed DNS responses, so if you previously did a DNS lookup for lets say api.example.org and got a IP of "8.8.4.4", the sniffer can then replace all occurences of 8.8.4.4 later with api.example.org

Or, it can do a so called rDNS or reverse DNS lookup. This means you do a lookup for a PTR record for the IP in reverse, so the rDNS of 8.8.4.4 can be found at a PTR for 4.4.8.8.in-addr.arpa which results in google-public-dns-b.google.com, thus the sniffer can replace all occurences of 8.8.4.4 with google-public-dns-b.google.com

Since you only can see the API destionation for some of the traffic, I suspect its the first case that is valid here, because if you did the DNS lookup prior to running the sniffer, this lookup is then cached for a period in your phone, which means that if the server in question lacks a rDNS value, the sniffer will normally display a IP instead of caonical name, which can give the apperance that some destinations are "encrypted" when they really are not.

If you want to hide the API destination from sniffing, you have to use some sort of proxy or VPN, where the traffic between the client and proxy/VPN is encrypted.

  • I'm not sniffing. I have a mobile application called Packet Capture which assign a certificate to my mobile. Not using sniffer! – m1lak0 Jul 31 '16 at 19:06
  • 2
    @m1lak0 Capturing packets is by definition sniffing – Fluffy Aug 1 '16 at 8:29

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.