Port forwarding compromises privacy?

[FPyro 2]

Hi!

Is it true that forwarding a port for p2p applications for example reduces your privacy and poses additional security risks?

I'm really happy the feature is available, but I might not use it so much if it's very risky. It's not like p2p doesn't work without an open port...just not as fast maybe.

And technically, how does it work anyway? Maybe you could explain in a few easy terms?

Thanks

[Staff 9972]

Hi!

Is it true that forwarding a port for p2p applications for example reduces your privacy and poses additional security risks?

I'm really happy the feature is available, but I might not use it so much if it's very risky. It's not like p2p doesn't work without an open port...just not as fast maybe.

And technically, how does it work anyway? Maybe you could explain in a few easy terms?

Thanks

Hello!

Technically it works via a 'DNAT'. Packets reaching a remotely forwarded port on our servers exit-IP addresses are forwarded to the correct VPN IP:local port of the client.

Security risks may come from correlation attacks. Prevent them by NOT opening on your router the same ports you have remotely forwarded (or just apply the firewall rules to prevent any leak according to our guides - they will also prevent any correlation attack based on port forwarding).

For latest uTorrent versions and any other torrent client that can successfully 'punch' a p2p-friendly cone-NAT, remote port forwarding is not strictly necessary, not even for performance.

Kind regards

[FPyro 2]

Hello!

Thanks for your fast answer. I'm trying to understand why some provider claim port forwarding increases risks and reduces privacy!

How would the latter disadvantage be possible?

Can somebody from the outside identify somebody, just because that person always has the same port forwarded?

In your opinion there isn't much (or any) performance increase by opening a port (IF uTP is enabled).

Or do you mean to by p2p-friendly cone NAT to enable NAT-PMP in utorrent? (Or Vuze, which supports both features as well).

And most importantly, what would such a correlation attack look like exaclty? How would I know I'm being attacked or the attack is successful?

And would comodo prevent such an attack even IF both my router and your servers forward the same port?

Thanks you, this is a most interesting topic

[Staff 9972]

Hello!

Thanks for your fast answer. I'm trying to understand why some provider claim port forwarding increases risks and reduces privacy!

How would the latter disadvantage be possible?

Can somebody from the outside identify somebody, just because that person always has the same port forwarded?

Hello!

Probably the claims of the providers you cite refer to a particular case of the wider 'identity-separation" issue. In the p2p field, if you connect to a swarm both when connected and disconnected to the VPN, and the torrent client always listens to the same port, you leave a hint (in most cases, totally useless) that a client using a VPN server is the same client that you used when not connected to the VPN. There are much more significant cases where using the same identity behind and not behind the VPN can expose to much stronger correlation attacks. A typical, even though stupid, example is when you log in a web site with the same account both when connected and not connected to the VPN.

In your opinion there isn't much (or any) performance increase by opening a port (IF uTP is enabled).

Or do you mean to by p2p-friendly cone NAT to enable NAT-PMP in utorrent? (Or Vuze, which supports both features as well).

No, as long as you have a green token, a performance difference should be noted only during the initial time needed by the torrent client to punch the NAT (in order to punch it, it needs help from other peers, so you might experience some minutes delay during which the token stays yellow and the client is unable to receive incoming packets).

And most importantly, what would such a correlation attack look like exaclty? How would I know I'm being attacked or the attack is successful?

It's difficult to notice them.

The adversary must have the ability to monitor your line.

In that case, the adversary may notice that you're connecting to a VPN server. It must also be able to understand that the IP address you connect to belongs to a VPN server which sends out your packet from a different IP address (the exit-IP of our servers), so it must also know this feature in our system. Once the adversary has got all these information, he/she can try to send packets to all ports of the VPN server exit-IP address and notice which packets receive a reply.

After that, the adversary must send, to the very same ports, packets to your real IP address. If he/she receives an answer on some port from your real IP address (assuming that your system is misconfigured, i.e. you have opened in the router the same ports that you remotely forwarded on our system), the adversary has a hint that the very same service responding to the same port on the VPN exit-IP is yours. At this point, the adversary can collect more evidence by performing timed packets sending toward the same ports on the VPN exit-IP and on your real IP address.

Other types of correlation attacks are not possible. They would be possible only if the VPN server had the same entry and exit-IP addresses, in which case the adversary would have an additional, significant option to perform an attack from inside the VPN: two clients connecting to the same VPN server and exchanging packets between each other would exchange those packets unencrypted OUT of the tunnel (this is due to how a VPN works), immediately allowing the attacker to discover the client real IP address, without even the need to monitor your line.

This a typical vulnerability of all VPN services which send out your packets from the same IP address your clients connects to, i.e. all VPN services which don't have separate shared entry-IP and exit-IP addresses (and there are many 'out there').

And would comodo prevent such an attack even IF both my router and your servers forward the same port?

Yes, if configured according to our guide, Comodo will doom the aforementioned attacks to total failure even if your router ports are open, because no service will ever be able to send packets outside the tunnel in response to an incoming packet to your real IP address. However, in an environment where exit-IP and entry-IP are the same (which is not the case in our service: in addition to separate entry and exit-IPs, no packet with entry-IP as destination IP is forwarded to any client VPN IP address, i.e. no packet with destination the entry-IP is ever forwarded to VPN clients) those rules will be impotent against the other type of attack above mentioned.

Kind regards

[Staff 9972]

Hello!

Thanks for your fast answer. I'm trying to understand why some provider claim port forwarding increases risks and reduces privacy!

To sum up all the previous replies...

A VPN provider may correctly claim that remote port forwarding ON ITS SYSTEM lowers security if its system is badly configured (same shared entry-IP and exit-IP).

In all other cases, a breach in the anonymity layer can come only from bad behavior of the customer, regardless of remotely forwarded ports or not.

Obviously the security patch of a lazy provider would be not to provide remote port forwarding options at all. This would also solve the problem of services which are run behind a VPN server. Since we strongly want to remain on our role of mere conduit, we have walked a completely different road, leaving total freedom to our customers whether to use or not remote port forwarding, and protecting the customer anyway in the best technical possible way if he/she decides to forward ports.

We don't take into considerations wrong behaviors of the customers which in any case can't be prevented and that are not strictly related to remote port forwarding: a VPN can't secure in any way a customer wrong behavior. There's nothing a VPN provider can do, just to make an extreme example, if a customer logs in a service with an account bound to his/her real name or willingly sends out identity disclosing information while connected to a VPN, or in general if the customer mixes up VPN identity and real identity.

Kind regards

[FPyro 2]

Hi,

I appreciate your detailed and very informative answer. Some topics should be something like a "sticky" like in other forums where you can see them right away on the first page... maybe this one would qualify? Would be a good idea for this forum anyway, wouldn't it?

If I'm not very much mistaken, almost no VPN provider goes to the trouble of having a different entry from exit IP address for each of their servers! I've not tested every vpn there is of course, but a few bigger, quite popular ones definitely don't have that additional security.

If what you say is true - and I don't doubt it - then all those other providers offering port forwarding like that would expose their customers to some serious security risks? Well, I'm glad I'm here!

I'm a bit worried about the last past of your answer though. If I trust the website I visit, like amazon for example, and I login with my usual ip, then connect to the vpn and login again at amazon (because I cleaned my browser before connecting), that behaviour wouldn't compromise my anonymity on any other site, would it?

cheers

pyro