Jump to content

Is it possible to bypass VOIP block in UAE y by using WebRTC clients ?

fun_egg

My sister lives in UAE and I am in india so there is no way for us to video chat for free, services like skype, whatsapp all are banned from providing VoIP service there. So i was wondering if it is possible to use a WebRTC client hosted in Heroku or AWS might be able to by pass the restrictions. Sice WebRTC is a standard protocol and it serves over TLS i though it might work. What are your thoughts on this.

 

or is there any other custom self hosted services out there  which can accomplish my requirements.

 

 

EDIT:-

They have banned the use of VPNs also

https://www.zdnet.com/article/getting-caught-in-the-uae-using-a-vpn-will-cost-you-over-500000/

Link to comment
Share on other sites

Link to post
Share on other sites

1 minute ago, fun_egg said:

My sister lives in UAE and I am in india so there is no way for us to video chat for free, services like skype, whatsapp and are banned from providing VoIP service there. So i was wondering if it is possible to use a WebRTC client hosted in Heroku or AWS might be able to by pass the restrictions. Sice WebRTC is a standard protocol and it serves over TLS i though it might work. What are your thoughts on this.

 

or is there any other custom self hosted services out there  which can accomplish my requirements.

 

Not really?

 

Like what you need is a both your machines to VPN to each other, or through a third party, and then just use generic VoIP software over that tunnel (eg via a SRTP connection.)

 

If they are blocking generic VoIP-like services, but not VPN, that might be an option. WebRTC is not designed for this however, and you would still need a VPN tunnel to protect the connection setup.

Link to comment
Share on other sites

Link to post
Share on other sites

Last time I had to video call someone (I live in a neighboring country) I used Google Duo, that seemed to work fine without having to use a VPN like other apps.

Link to comment
Share on other sites

Link to post
Share on other sites

1 minute ago, Kisai said:

 

Not really?

 

Like what you need is a both your machines to VPN to each other, or through a third party, and then just use generic VoIP software over that tunnel (eg via a SRTP connection.)

 

If they are blocking generic VoIP-like services, but not VPN, that might be an option. WebRTC is not designed for this however, and you would still need a VPN tunnel to protect the connection setup.

They have banned the use of VPNs also,

 

https://www.zdnet.com/article/getting-caught-in-the-uae-using-a-vpn-will-cost-you-over-500000/

Link to comment
Share on other sites

Link to post
Share on other sites

3 minutes ago, Kisai said:

 WebRTC is not designed for this however, and you would still need a VPN tunnel to protect the connection setup.

can you please explain this ? am not an expert in protocols and all.

Link to comment
Share on other sites

Link to post
Share on other sites

Just now, fun_egg said:

Then there's no practical solution that wouldn't be illegal.

 

I would almost recommend if the entire goal is to avoid paying extortionate costs for phone calls, join the same twitch/mixer/youtube/kast/discord/slack/teams/skype, whatever works, and instead of treating it as a VoIP session, treat it as a group session with only two participants.

Link to comment
Share on other sites

Link to post
Share on other sites

2 minutes ago, Kisai said:

Then there's no practical solution that wouldn't be illegal.

 

I would almost recommend if the entire goal is to avoid paying extortionate costs for phone calls, join the same twitch/mixer/youtube/kast/discord/slack/teams/skype, whatever works, and instead of treating it as a VoIP session, treat it as a group session with only two participants.

Why wont a WebRTC connection work ? its just plain http trafic right ? since i am running from my own server there is no way for them to find out that i am using this WebRTC session for video calling or am i missing something here ?

Link to comment
Share on other sites

Link to post
Share on other sites

6 minutes ago, fun_egg said:

can you please explain this ? am not an expert in protocols and all.

Basically WebRTC is trying to push VoIP over regular TLS (port 443), but that entire connection setup is not protected since if someone wanted to spy on it, they could see who you're connecting to, and block it if that was the intent.

 

I would not rely on "web" technologies for this purpose as nearly everything is based on Chromium, and Google has a penchant for discarding experimental features, and presently the WebRTC feature is incomplete.

 

As an aside. It is NOT HARD to setup a third party server to just run a straight RTMP server and then use OBS to stream video to it, and then have someone else connect to it. If you do that in both directions you have a Quasi-VoIP service that only works with two participants.

 

There is also services like Kast which lets participants create a pseudo-meeting like Teams or Youtube hangouts work.

 

Like I don't know the specifics of what the UAE is requiring or what is legal, so these are just ways to avoid the extortion rather than trying to address the security of the connection. The connection can only be secured if you trust everyone, and that's simply not going to be a thing if the government demands the keys to the intermediaries. 

Link to comment
Share on other sites

Link to post
Share on other sites

It depends on how the block is implemented. Your best bet is to just try it out.

 

 

1 hour ago, Kisai said:

Basically WebRTC is trying to push VoIP over regular TLS (port 443), but that entire connection setup is not protected since if someone wanted to spy on it, they could see who you're connecting to, and block it if that was the intent.

What do you define as "the entire connection setup" and where did you get this info from?

The reason why I am asking is because it does not match my understanding of WebRTC.

 

 

1 hour ago, Kisai said:

I would not rely on "web" technologies for this purpose as nearly everything is based on Chromium, and Google has a penchant for discarding experimental features, and presently the WebRTC feature is incomplete.

Source?

What exactly is incomplete about WebRTC? Also, why do you think WebRTC is based on Chromium? It's a web standard and there are a wide variety of implementations of it.

 

1 hour ago, Kisai said:

Like I don't know the specifics of what the UAE is requiring or what is legal, so these are just ways to avoid the extortion rather than trying to address the security of the connection. The connection can only be secured if you trust everyone, and that's simply not going to be a thing if the government demands the keys to the intermediaries. 

You don't need to trust all parties involved. I think that's a fundamental misunderstanding of how encryption works.

The only one you need to trust to have a secure connection is the other client. With proper E2EE only you and the intended recipient will be able to see the messages, and there won't be any trust in the ISPs or the likes necessary to ensure that.

Link to comment
Share on other sites

Link to post
Share on other sites

6 hours ago, LAwLz said:

What do you define as "the entire connection setup" and where did you get this info from?

The reason why I am asking is because it does not match my understanding of WebRTC.

 

 

It's the same problem torrents have. ISP's got wise, then torrent clients encrypted it so it looks like VPN traffic, then the ISP's just throttled the hell out of all encrypted traffic. Then users just connected through VPN service providers, and ISP's still throttled it. The quickest way to wreck an emerging piece of tech is to make it work over an existing mechanism, which is why just about everything has to work over HTTPS now, and the web has become super-fragile. You have to be kidding yourself if a country that already bans VPN's and some VOIP software won't just outright block peer to peer web connections.

 

https://torrentfreak.com/huge-security-flaw-leaks-vpn-users-real-ip-addresses-150130/

 

Quote

“Perhaps the best way to be protected from WebRTC and similar vulnerabilities is to run the VPN tunnel directly on the router. This allows the user to be connected to a VPN directly via Wi-Fi, leaving no possibility of a rogue script bypassing a software VPN tunnel and finding one’s real IP,” Van der Pelt says.

One of these days Google Chrome devs will stop trying to be Facebook and implement features in a "off-by-default" manner, instead of "abusable by default" like WASM.

Link to comment
Share on other sites

Link to post
Share on other sites

5 hours ago, Kisai said:

ISP's got wise, then torrent clients encrypted it so it looks like VPN traffic

They never did that.

 

5 hours ago, Kisai said:

then the ISP's just throttled the hell out of all encrypted traffic.

No they haven't.

 

5 hours ago, Kisai said:

Then users just connected through VPN service providers, and ISP's still throttled it.

That one is true, in some cases.

 

5 hours ago, Kisai said:

The quickest way to wreck an emerging piece of tech is to make it work over an existing mechanism, which is why just about everything has to work over HTTPS now, and the web has become super-fragile.

I could not disagree more. WebRTC doesn't even use HTTPS ports for anything more than signaling. For the actual communication traffic it uses a random port number.

 

5 hours ago, Kisai said:

You have to be kidding yourself if a country that already bans VPN's and some VOIP software won't just outright block peer to peer web connections.

How do you propose they do that?

How do you propose they block peer to peer traffic?

 

 

5 hours ago, Kisai said:

That's irrelevant to the discussion.

That's just about how WebRTC can be used to leak your IP even when you're using a VPN. That's not a problem in this situation.

 

 

5 hours ago, Kisai said:

One of these days Google Chrome devs will stop trying to be Facebook and implement features in a "off-by-default" manner, instead of "abusable by default" like WASM.

I believe both WebRTC and WASM should be enabled by default. Just because they might be used for nefarious means doesn't mean they are bad. It's like saying "well most viruses are written in C so maybe Windows shouldn't allow C code to run by default!".

Link to comment
Share on other sites

Link to post
Share on other sites

5 hours ago, LAwLz said:

 

How do you propose they do that?

How do you propose they block peer to peer traffic?

 

You aren't serious. You know how NAT works right? You know how firewalls work right? You know how DNS works right?

 

The government tells the ISP's that all traffic must go through the national firewall before reaching the internet, or even leaving the ISP's domestic network. That's pretty much what China does.

 

https://en.wikipedia.org/wiki/Great_Firewall#Blocking_methods

 

Quote

IP range ban using black holes

DNS spoofing, filtering and redirection

URL filtering using transparent proxies

Quality of service filtering

Packet forging and TCP reset attacks

Man-in-the-middle attacks with TLS

 

That Packet forging and TCP reset attacks is how ALL domestic ISP's engaged in damaging bittorrent and is what prompted the encryption of it. Gee wow this user uploads more than they download, they must be a dirty pirate, pwn that guy.

 

These countries trying to prevent their own citizens from talking to anyone through unauthorized channels will clamp down on anything that threatens their control. Block all traffic that doesn't go through the government controlled proxy service. Corporate networks have been doing that forever.

Link to comment
Share on other sites

Link to post
Share on other sites

3 hours ago, Kisai said:

You aren't serious. You know how NAT works right? You know how firewalls work right? You know how DNS works right?

Yes I do. Now explain how you would use those to block a WebRTC connection where the server was running on for example OP's computer. 

I don't see how NAT plays a role in this and I don't see how DNS plays a role in this scenario. 

 

3 hours ago, Kisai said:

The government tells the ISP's that all traffic must go through the national firewall before reaching the internet, or even leaving the ISP's domestic network. That's pretty much what China does.

 

https://en.wikipedia.org/wiki/Great_Firewall#Blocking_methods

And how exactly would that firewall block this particular type of connection? 

 


 

-IP range ban using black holes

Wouldn't work since it would be hosted on a random, unknown IP. 

 

-DNS spoofing, filtering and redirection

URL filtering using transparent proxie

Wouldn't work since it wouldn't have to use DNS OR ANY URL. 

 

-Quality of service filtering

Might be doable but they would essentially need to throttle all UDP traffic, which they won't unless they are willing to break pretty much everything on the internet just to catch someone try to get away with an exotic type of VoIP to save some money. 

 

-Packet forging and TCP reset attacks

Wouldn't work. Can't forge packets when it's encrypted, and WebRTC doesn't use TCP so it's immune to resets. 

 

-Man-in-the-middle attacks with TLS

Wouldn't work unless a root certificate which I assume isn't installed on the receptions phone. 

 

 

3 hours ago, Kisai said:

Packet forging and TCP reset attacks is how ALL domestic ISP's engaged in damaging bittorrent and is what prompted the encryption of it. Gee wow this user uploads more than they download, they must be a dirty pirate, pwn that guy.

And like I said, WebRTC is iuume to both of those attacks. And I don't see how those two types of attacks could be used to block bittorrent traffic either. Got a source for that claim? Bittorrent is also UDP based so it can't be attacked by reset packets.

 

Got s source on ISPs making these assumptions thst if you upload more than you download, you must be a pirate? I'd guess that most people don't seed a lot so it seems backwards to me. Downloading more than you upload would be the typical traffic pattern I'd expect from a pirate, but it's exactly the same pattern I'd expect from a normal user too. 

Link to comment
Share on other sites

Link to post
Share on other sites

3 hours ago, Kisai said:

No they didn't. 

Encryption != make it look like VPN traffic. 

 

If you look at the data stream for encrypted bittorrent traffic and compare it to the data stream for let's say an IPsec connection you'll see that they look very different. 

Link to comment
Share on other sites

Link to post
Share on other sites

@LAwLz So is there any way that i could WebRTC client hosted in heroku to by pass the restrictions ?

Link to comment
Share on other sites

Link to post
Share on other sites

2 hours ago, fun_egg said:

@LAwLz So is there any way that i could WebRTC client hosted in heroku to by pass the restrictions ?

Hard to tell. It should work though. Just try it out and see. If you don't want to spend money on Heroku just to try it out you could try Google Cloud (they have a free option) or run it on your own computer as a proof of concept. 

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×