They can block the default port and IP addresses owned by VPN service providers, but is there any way to block the protocol without block all encrypted web traffic?
Russia isn’t the USSR but it is heading towards the USSR ways, and it’s already there in many aspects. It’s not just on a technical definition, a lot of pro-war and nationalist rhetoric is rooted in the old USSR culture.
The USSR wasn’t socialist, it was communist. And yes I know, it wasn’t real communism because real communism is a utopia.
Russia isn’t implementing maternal paid leave, a good universal healthcare system, guaranteed housing, food, education, and a job, so it’s not heading for the ‘USSR ways’ and the USSR was socialist
It’s a custom protocol that uses SSL/TLS for key exchange and such, so it can be detected. It’s actually causing huge problems for many large Russian companies, as it’s common to use those protocols for remote access, work, etc.
As mentioned in the article you need something like “Shadowsocks” to avoid protocl blocking, since it fully disguises the traffic as standard SSL/TLS. Which was created for, and is still used to circumvent this type of blocking in “the great firewall of china”.
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.
There’s still headers and it’s fairly trivial to block using packet analysis. Using other protocols such as SSH tunneling may work (until they try to ban that I suppose). There’s always way around these kind of blocks, it’s a cat and mouse game.
It’s not, it’s an IPSec VPN by default which runs over UDP. You can run it via TCP and it operates over the same port as HTTPS (443), but it’s not the same protocol and can be differentiated that way.
A way around this would be to run an SSLVPN with a landing page where you log in instead of using an IPSec VPN or a dedicated SSLVPN client.
Another way around it would be to create a reverse SSH tunnel on a VM/VPC in another country/state and send all your traffic through that.
It’s not, it’s an IPSec VPN by default which runs over UDP. You can run it via TCP and it operates over the same port as HTTPS (443), but it’s not the same protocol and can be differentiated that way.
I think that either I’m misunderstanding what you’re aiming to say, or that this is incorrect.
OpenVPN can run over UDP or TCP, but it’s not IPSec, not even when running over UDP. IPSec is an entirely separate protocol.
Is OpenVPN not just SSL traffic?
They can block the default port and IP addresses owned by VPN service providers, but is there any way to block the protocol without block all encrypted web traffic?
Blocking all encrypted traffic… fantastic suggestion comrade, I’ll forward this on to the Kremlin. Also, you’ve been drafted.
I suppose with “comrade” you are hinting at Soviet customs, but Russia isn’t the USSR and couldn’t be further from being socialist
Settle down, it was a joke
what
deleted by creator
Russia isn’t the USSR but it is heading towards the USSR ways, and it’s already there in many aspects. It’s not just on a technical definition, a lot of pro-war and nationalist rhetoric is rooted in the old USSR culture.
The USSR wasn’t socialist, it was communist. And yes I know, it wasn’t real communism because real communism is a utopia.
Russia isn’t implementing maternal paid leave, a good universal healthcare system, guaranteed housing, food, education, and a job, so it’s not heading for the ‘USSR ways’ and the USSR was socialist
Oh please. In all the ways that matter, it is identical.
It’s a custom protocol that uses SSL/TLS for key exchange and such, so it can be detected. It’s actually causing huge problems for many large Russian companies, as it’s common to use those protocols for remote access, work, etc.
As mentioned in the article you need something like “Shadowsocks” to avoid protocl blocking, since it fully disguises the traffic as standard SSL/TLS. Which was created for, and is still used to circumvent this type of blocking in “the great firewall of china”.
https://security.stackexchange.com/questions/187649/is-it-possible-to-detect-vpn-in-the-network
tl;dr: You can infer that OpenVPN is used from the key exchange somehow.
deleted by creator
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.
Yes there is a difference between https traffic.
There’s still headers and it’s fairly trivial to block using packet analysis. Using other protocols such as SSH tunneling may work (until they try to ban that I suppose). There’s always way around these kind of blocks, it’s a cat and mouse game.
It’s not, it’s an IPSec VPN by default which runs over UDP. You can run it via TCP and it operates over the same port as HTTPS (443), but it’s not the same protocol and can be differentiated that way.
A way around this would be to run an SSLVPN with a landing page where you log in instead of using an IPSec VPN or a dedicated SSLVPN client.
Another way around it would be to create a reverse SSH tunnel on a VM/VPC in another country/state and send all your traffic through that.
I think that either I’m misunderstanding what you’re aiming to say, or that this is incorrect.
OpenVPN can run over UDP or TCP, but it’s not IPSec, not even when running over UDP. IPSec is an entirely separate protocol.