SSL is a higher layer thing, isn’t it? A VPN is just encapsulating an IP packet in another IP packet and getting it to the tunnel endpoint. Unless the whole of the inner IP packet is encrypted, the service provider could just sniff your packets and block anything that looks like an IP packet in the outer packet payload?
Unless the whole of the inner IP packet is encrypted,
It is, because they’re inside an encrypted stream of data.
The way OpenVPN works is this:
OpenVPN establishes a TLS connection to the OpenVPN server.
Your computer’s kernel generates an IP packet.
OpenVPN sucks that up, shoves it into the TLS connection. That connection is encrypted, so the network provider cannot see inside it, know whether the data is IP packets or anything else, though I suppose maybe traffic analysis might let one classify a connection as probably being a VPN.
The data in that connection is broken up into IP packets, went to the OpenVPN server.
The OpenVPN server decrypts the data in the TLS stream, pulls the original IP packets out.
So the original packets are always encrypted when the network sees them. Only the OpenVPN server can see the unencrypted packet you originally sent.
What @raltoid is saying sounds plausible, though I can’t confirm it myself off-the-cuff – that OpenVPN is detected by looking at somehing unique in the initial handshake.
VPN detection is simple: track new encrypted connections outside of Russia, connect to the same server, check if it replies as a VPN server. If it does, block the shit out of it. No need for packet inspection or any voodoo.
Fair enough. I mean, there are ways around that too, like some port knocking scheme, but I assume that this shadowsocks thing solves the same problem in a better way.
But I do stand by what I was responding to on, the bit about the internal IP packets being encrypted and not readable.
SSL is a higher layer thing, isn’t it? A VPN is just encapsulating an IP packet in another IP packet and getting it to the tunnel endpoint. Unless the whole of the inner IP packet is encrypted, the service provider could just sniff your packets and block anything that looks like an IP packet in the outer packet payload?
It is, because they’re inside an encrypted stream of data.
The way OpenVPN works is this:
OpenVPN establishes a TLS connection to the OpenVPN server.
Your computer’s kernel generates an IP packet.
OpenVPN sucks that up, shoves it into the TLS connection. That connection is encrypted, so the network provider cannot see inside it, know whether the data is IP packets or anything else, though I suppose maybe traffic analysis might let one classify a connection as probably being a VPN.
The data in that connection is broken up into IP packets, went to the OpenVPN server.
The OpenVPN server decrypts the data in the TLS stream, pulls the original IP packets out.
So the original packets are always encrypted when the network sees them. Only the OpenVPN server can see the unencrypted packet you originally sent.
What @raltoid is saying sounds plausible, though I can’t confirm it myself off-the-cuff – that OpenVPN is detected by looking at somehing unique in the initial handshake.
VPN detection is simple: track new encrypted connections outside of Russia, connect to the same server, check if it replies as a VPN server. If it does, block the shit out of it. No need for packet inspection or any voodoo.
Fair enough. I mean, there are ways around that too, like some port knocking scheme, but I assume that this shadowsocks thing solves the same problem in a better way.
But I do stand by what I was responding to on, the bit about the internal IP packets being encrypted and not readable.