Just realized, this can use a bit more explanation:
I mean it encrypts the whole internet package, right? does that include stuff like the size of the package?
Yes, VPNs encrypt the data being passed between the VPN client and server. But it doesn't make the size of the content "disappear".
So, say you want to download a file of 2MiB. All networks have a restriction of how large each network packet can be. This various slightly, but a very common value is 1500 bytes (this is a fairly comprehensive topic, but MTU and Ethernet frames are keyword). Each packet includes both MAC and IP headers (for TCP/IP traffic), and inside IP headers are your local IP address as well as the destination IP address found. And then comes the payload (the data you want to transfer). But due to this restriction, and the packet header information you have less than 1500 bytes per packet available when trying to transfer this 2MiB file. So what happens is that this large transfer is (automatically) chopped up into smaller pieces, fitting into the maximum capacity you can use. On the receiving side, all these fragments are then assembled and saved to a single file again.
When you add VPN into this mix, the VPN interface will receive a stream of packets, as described above. It will then encrypt each of these packets individually (hiding the contents) and then it will be sent further to the VPN host, which means another set of packet headers (which cannot be encrypted) together with the encrypted payload. The receiving side will then decrypt the payload and pass that to its local VPN interface again, containing the packet headers the sending side used.
What this means is that VPN will give an additional overhead and the effect of the available maximum size for the payload will be further reduced. Again, this is quite a complex topic, as there are approaches to try to avoid too much fragmentation on the VPN packets. But the effect is regardless that VPN in practice reduces the overall "transfer capacity" per network packet.
This means you will in almost all cases spend more data transferring packets passed over the VPN. To illustrate this, here's a (reordered) statistic of a VPN session on my computer. Here are both the packet and byte counters for traffic being sent to the VPN interface (TUN_BYTES_IN/TUN_PACKETS_IN). They are encrypted and sent out to the insecure Internet (BYTES_OUT/PACKETS_OUT)
What you see here is that more data is being sent to the VPN server than was received on the VPN interface. This is because encrypted network packets bigger and need additional splitting.
And for the traffice being sent from the VPN server to my client. BYTES_IN/PACKETS_IN is the encrypted data coming from the VPN server. TUN_BYTES_OUT/TUN_PACKETS_OUT is the decrypted data being sent to the VPN interface.
When receiving encrypted data from the VPN server, we see the reverse effect. We send less data/packets to the VPN interface, because decrypting the packets reduces the size.
And then you might wonder about compression. Compression is an alternative which may be used to reduce this overhead - when the traffic is compressible. But first of all, compression will reduce the security of the VPN tunnel. In addition a lot of the data being transported is already fairly compressed (like .mp3/.avi/.jpg files) or not suitable to compress (like https traffic) - both these cases will not result in much compression effect. So it is not recommended to use compression at all.
So to sum it up: VPNs will not hide the size of the data being transported. The effect will be that you use more data when using VPNs.
Makes tons of sense, thanks David for the explanation 😊
Just realized, this can use a bit more explanation:
Yes, VPNs encrypt the data being passed between the VPN client and server. But it doesn't make the size of the content "disappear".
So, say you want to download a file of 2MiB. All networks have a restriction of how large each network packet can be. This various slightly, but a very common value is 1500 bytes (this is a fairly comprehensive topic, but MTU and Ethernet frames are keyword). Each packet includes both MAC and IP headers (for TCP/IP traffic), and inside IP headers are your local IP address as well as the destination IP address found. And then comes the payload (the data you want to transfer). But due to this restriction, and the packet header information you have less than 1500 bytes per packet available when trying to transfer this 2MiB file. So what happens is that this large transfer is (automatically) chopped up into smaller pieces, fitting into the maximum capacity you can use. On the receiving side, all these fragments are then assembled and saved to a single file again.
When you add VPN into this mix, the VPN interface will receive a stream of packets, as described above. It will then encrypt each of these packets individually (hiding the contents) and then it will be sent further to the VPN host, which means another set of packet headers (which cannot be encrypted) together with the encrypted payload. The receiving side will then decrypt the payload and pass that to its local VPN interface again, containing the packet headers the sending side used.
What this means is that VPN will give an additional overhead and the effect of the available maximum size for the payload will be further reduced. Again, this is quite a complex topic, as there are approaches to try to avoid too much fragmentation on the VPN packets. But the effect is regardless that VPN in practice reduces the overall "transfer capacity" per network packet.
This means you will in almost all cases spend more data transferring packets passed over the VPN. To illustrate this, here's a (reordered) statistic of a VPN session on my computer. Here are both the packet and byte counters for traffic being sent to the VPN interface (TUN_BYTES_IN/TUN_PACKETS_IN). They are encrypted and sent out to the insecure Internet (BYTES_OUT/PACKETS_OUT)
What you see here is that more data is being sent to the VPN server than was received on the VPN interface. This is because encrypted network packets bigger and need additional splitting.
And for the traffice being sent from the VPN server to my client. BYTES_IN/PACKETS_IN is the encrypted data coming from the VPN server. TUN_BYTES_OUT/TUN_PACKETS_OUT is the decrypted data being sent to the VPN interface.
When receiving encrypted data from the VPN server, we see the reverse effect. We send less data/packets to the VPN interface, because decrypting the packets reduces the size.
And then you might wonder about compression. Compression is an alternative which may be used to reduce this overhead - when the traffic is compressible. But first of all, compression will reduce the security of the VPN tunnel. In addition a lot of the data being transported is already fairly compressed (like .mp3/.avi/.jpg files) or not suitable to compress (like https traffic) - both these cases will not result in much compression effect. So it is not recommended to use compression at all.
So to sum it up: VPNs will not hide the size of the data being transported. The effect will be that you use more data when using VPNs.
Ah, I see now...
It's actually shocking to know that VPN has the opposite effect on data size, regardless of how many falsified articles claim 😁
BTW guys, David is the team lead core dev of OpenVPN Inc.
Thanks a lot David for the explanation!