# How is it possible for a VPN connection to be created through the ISP?

I will be theoretical here. Let's say you want to create a VPN connection with some VPN provider. You have to agree on some key to encrypt the data. how can you get the key without your ISP knowing it? Even if you are the one who creates the key, the ISP still sees it as it's being sent to the VPN provider.

An analogy would be, say... Alice(you, or the client), John(ISP), and Bob(VPN provider) are sitting in a room. Alice is trying to convey a message to Bob without John understanding it. So Alice tells Bob that they will speak French(instead of English). Now john knows their language. no accomplishment. Even if Alice talked about a complex method of encrypting the message, John will know it, since he is in the room.

Unless Alice and Bob had agreed on a method before they were in the room, they won't be able to communicate privately.

An other way would be for Alice and Bob to already have some keyword X which only they know, which counts as 'a method before they were in the room', but I think that's unlikely in a VPN.

End of analogy...

So how is it possible for you and VPN provider to communicatea key without ISP knowing it?

• Using the magic of asymmetric cryptography. – SEJPM Jul 6 '18 at 12:02
• Thanks, that's really magical! So you would send an encrypted message(containing a key) to a VPN provider using its public key, and it will use the key to communicate back? – JavaLearner Jul 6 '18 at 12:11
• If you use TLS with one of the ciphersuites without DH / DHE / ECDH / ECDHE in their name, yes, that's essentially what happens. – SEJPM Jul 6 '18 at 12:15

So how is it possible for you and VPN provider to communicate a key without ISP knowing [that you are communicating]?

You can't. The ISP will always see that there is some traffic going on. Whether the ISP will be able to see with whom you are (actually) talking depends on whether you use things like TOR and on the details of the target network, but in general the packet metadata will tell the ISP where to send the packet and thus with whom you are talking.

So how is it possible for you and VPN provider to communicate a key without ISP knowing [the key used to encrypt the data]?

This is due to the "magic" of asymmetric cryptography. In short, this allows you to reduce the requirement from a trusted, secret channel (to transport a symmetric key) down to an authentic channel, ie a channel where nobody gets to alter, drop or insert malicious messages***. And as you may have guessed, in current TLS versions (1.2 and earlier**), if you use a so-called "ciphersuite" without DH, DHE, ECDHE or ECDH in the name, you are essentially encrypting a secret with the server's public key, sending it and then you both go from there and derive a key* for the session.

*: To get some neat extra security properties.
**: TLS 1.3 has explicitely removed this type of ciphersuite because of something called forward secrecy.
***: So-called certificates are then used to reduce this requirement even further from "always need authentic channel" to "sometimes need authentic channel + need to trust a third party"

@SEJPM's answer is quite complete. I want to follow up with SEJPM's description of authenticated channels.

My claim is:

The authenticated channel does not exist UNLESS you make some assumptions.

You can access the server of the VPN provider, create an account, and pay the money online. The prerequisite is that you can access the real website of the VPN provider.

This is possible because of the Public Key Infrastructure (PKI). Your computer stores some certificates of trusted parties (root authorities). They use their cryptographic signing keys to sign the website certificates for the real website owners.

For example, the certificate of StackExchange is signed by DigiCert Inc.

However, we have to trust these root authorities. If they misbehave, the authenticated channels disappear. Sees here for a news on Google banning HTTPS certificates from WoSign and StartCom due to misbehaving.

If your computer is installed with a fake certificate of a root authority, the network connections are no longer secure.

And it is real. Some corporate-scale content filters [1] use a fake root authority to break the SSL security of network communications in order to inspect employees' network connections.

[1] Analyzing Forged SSL Certificates in the Wild. Lin Shung Huang, Alex Rice, Erling Ellingsen, and Collin Jackson. https://ieeexplore.ieee.org/abstract/document/6956558/. (open access)