I understand how using a public VPN service can make network connectivity more secure in case of HTTP, or even HTTPS a without certificate pinning in place.

Suppose we have a fat client application that uses SSL pinning for all HTTPS communication with our servers. What extra advantages can using public VPN service add to our application (not the rest of the system) from the security perspective?

  • 1
    One big win is anonymity. Without VPN, your ISP will know you connected to this service.
    – Anders
    Jun 8, 2016 at 18:38
  • @Anders Great observation and definitely a huge benefit! :) Thank you. Jun 8, 2016 at 18:39

1 Answer 1


You are mixing up concepts that counter vastly different threat models and thus you question is hard to answer.

Let's say a hypothetical connection path would look like this:

A <-> B <-> C <-> D <-> E <-> F


  • A being the client,
  • B being a public WiFi you are connected to,
  • C being the ISP of the WiFi provider,
  • D and E being intermediate hops between ISPs and
  • F being your target to which A is connecting.


A VPN establishes a secure tunnel between your machine and the end point of the tunnel, not more. In the example path, this would cover B and C, maybe D. This has several benefits if you do not trust your local ISP; maybe because that ISP is a public WiFi or otherwise untrustworthy and is expected to sniff your traffic:

  • If you use HTTP, it can only be sniffed (and modified) from the VPN provider onwards,
  • If you use HTTPS, your DNS queries cannot be sniffed (from B or C), thus hiding (from those) which sites you're visiting.

Either way, you do not hide your DNS queries from your VPN provider or its ISP.

An additional benefit is pseudonymity; you do not leak your ISP-assigned IP-Address, but that one of the VPN provider, adding an extra layer of depseudonymization to identifying you.

HTTPS with Public Key Pinning

Public Key Pinning (mainly) defeats two threats that would inter-operate:

  1. A man in the middle (B, C, D or E) that would break up the otherwise secure connection between A and F,

  2. A rouge certificate authority that creates certificates for 1. to be able to present to you and be validated correctly.

    A sub-threat to this would be that a dishonest CA could be installed in your trust store (e.g. by HTTPS proxies used in large organizations to actively inspect HTTPS connections for threats - but those are usually considered OK.

Public Key Pinning can thus defeat MITMs that can (for whatever reason) present (otherwise) valid certificates to break up the communication. This would allow B,C,D or E (not mutually exclusively) read and/or alter your HTTPS traffic.


A client that uses HPKP (correctly) is reasonably safe, albeit reducing usability: the before-mentioned HTTPS proxies would make communication impossible when it would otherwise be possible. In such cases, VPNs are usually not allowed, so a VPN wouldn't improve usability there.

A does however gain pseudonymity towards F by using a VPN, yet that is probably defied by an authentication feature within the application.

  • Thank you, this is a very nice and detailed answer. In our scenario, the idea would be to deploy VPN "end-to-end", from (mobile) client app to the back-end service provider (our server). But all the generic points are covered by your post. Nov 8, 2017 at 16:29
  • @PetrDvořák in that case, you do not gain anything by doing both (when done right) and both on their own have equivalent properties. Yet, an application would have to „trust“ that there is a VPN (or implement it itself, which is not good) vs. using the system TLS facilities and knowing the connection is safe.
    – Tobi Nary
    Nov 8, 2017 at 16:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .