3

I have tried to search this piece of information but have not found any clue so far, but I believe someone here can rectify me or answer my question with proper logic.

When we implement SSL Pinning in our Mobile Application (android/ios), the data packet can not be sniffed from Burp or Wireshark tools. So, my question here is, on the network where and who will get this encrypted packet and extract the domain name from it, and then will resolve it?

With SSL Pinning we are trying to hide this client&server communication, and when we are able to hide this, then who (which authority) will be able to read this package and then will extract the domain name form it, and pass the traffic to relevant server on the internet?

Nah
  • 1,690
  • 2
  • 26
  • 46

2 Answers2

0

SSL pinning basically ensures no one on the way accepts the packets over SSL which is not same as pinned ssl.

As far as sniffing data packets is concerned, it is not due to SSL pinning specifically but only due to SSL.

However your query about domain resolution, SSL pinning is not used for domain resolution, the domain gets resolved using a global OS resolver, it is not app specific, and there is no role of your domains SSL pinned certificate in domain resolution.

mdeora
  • 4,152
  • 2
  • 19
  • 29
  • I didn't understand it very much, need further explanation. how SSL pinned traffic packet reaches the target server? Ofcourse somewhere any device/system, might be extracting the domain name and resolving it to actual IP. If any device/system can do that then what is that specifically. Can it extract other data also from the packet (then it might also be a security risk)? – Nah Mar 15 '19 at 11:04
0

While I agree with @mdeora, I am attempting to explain (long way) what happens behind the scene in simple terms, and hope it will help.

Lets define few terms first

Client ("C"): a Mobile Application which uses SSL/TLS library. Also, Client may be configured to recognize certificates signed by an internal Certifying Authority (CA).

Server ("S"): a target server which serves the request

Proxy ("P") or Transparent proxy ("TP"): Which intercepts the SSL request, and presents an illusion to Client that it is indeed a target server, by sending a certificate on behalf of "S", but signed by an internal CA certificate created by proxy server. E.g. Burp Suite, Squid

DNS Servers: A service which resolves a name to IP address

Client DNS servers: One or more IP addresses of DNS server configured on mobile, either due to explicit configuration, or supplied by network connection when mobile device connects to network (telecom or Wifi)

Proxy DNS servers: One or more IP addresses of DNS servers configured on same machine where proxy service is configured

Case A. When neither proxy, nor transparent proxy present between the Client and the Server

  1. "C" finds an IP address (say "IP-S") of "S" by querying a Client DNS server.
  2. "C" uses SSL/TLS to connect to "IP-S" and completes the communication. Entire communication is encrypted.

In this case, Burp Suite / Wireshark cannot see a plain text traffic.

Case B. When a mobile is configured to use a proxy server "P"

  1. "C" finds an IP address of "P" by querying Client DNS server, say "IP-P".
  2. "C" connects to "IP-P" via HTTP or HTTPS protocol.
  3. If "C" connects to "P" via HTTP protocol, "P" intercepts the request, checks the URL, and gets a domain name.
  4. If "C" connects to "P" via HTTPS protocol, "P" will understand the target server name as part of SSL/TLS handshake via SNI -- an extension to SSL/TLS. (https://en.wikipedia.org/wiki/Server_Name_Indication)
  5. "P" will use a Proxy DNS server to get IP (say "IP-S") for "S". "P" will connect to "IP-S".
  6. Under a normal case, "P" (or "TP") would relay byte-by-byte request from "C" to "S" and response from "S" to "C". "C" will always get a real certificate of "S", and "P"/"TP" would not know anything beyond the fact that "C" is communicating with "S".
  7. However, in case of interceptors (e.g. BurpSuite), "P" (or "TP") will present a certificate signed by internal CA, impersonating "S". If "C" is configured to recognize certificates signed by internal CA, SSL library within "C" will be compelled to assume that it is indeed talking to "S".

Without SSL pinning, "C" will interact with "P" (or "TP") as if it is "S". "P" will decrypt the traffic, and establish a connection with "S", re-encrypt the traffic and sends it to "S". Same way, "P" will receive response from "S", and sends it back to "C". "C" and "S", both, will be unaware of the fact that "P" has intercepted (and may have altered) the traffic.

With SSL pinning (https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md), "C" will not proceed if it finds that certificate presented by "P"/"TP" does not match a real certificate of "S".

Case C. When a mobile is using a network where Transparent Proxy ("TP") is present

Here, "C" attempts to connect to "S" as in Case A, but "TP" present in the network intercepts the traffic just like "P" and rest is followed as Case B(4) onward.

To summarize, when you use SSL Pinning, "C" will communicate to "S" only if it believes that it is communicating over a secure channel to real "S", not a proxy.

Kishan Parekh
  • 341
  • 1
  • 8
  • You made your excellent answer very hard to read, just to try to save some key strokes. Please consider to use the full word instead. – Exadra37 Jun 03 '19 at 13:15