Question the Devs: Exit Node Responsibility and Legality

I have seen a recurring question in our social media channels about the safety and risks associated with operating a VPN exit node. The classic user scenario people are proposing is, “What happens if a malicious user accesses illegal content through my exit node?”

The answer to this is two pronged. First, operating an exit node for any proxy or VPN service is not without risks. Risk is unavoidable when allowing any person in the world to tunnel traffic through your network. Therefore, VPN and proxy exit node providers should be aware of and comply with all applicable local and international laws. The responsibility for these situations is strictly on the end user and provider. Consider that many people operate proxies, VPNs and TOR exit nodes for free, all while enduring this risk with zero benefit. Conversely, the benefit of operating a proxy or VPN server in the Intense network is guaranteed, immediate compensation for providing the service and absorbing that risk.

Second, the ITNS VPN has two critical mechanisms to prevent access to said resources, and mitigate risk when inappropriate resources are accessed. The first mechanism is an engineering control; exit nodes can restrict access to specific IPs, FQDNs, and ports. This feature offers tremendous capability. At the present time there are no plans to integrate this feature with an IP/FQDN reputation service or blacklist maintained by a third party, but this could easily be performed locally by a savvy system admin. As the VPN is powered by an OpenVPN server, an exit node provider can easily add readily available OpenVPN packages that block malicious and illegal content. Similarly, this can be added to the forward proxy software used for proxy servers.

The second mechanism is anonymized logging. The exit node VPN server has the capability to log traffic requested by clients in an anonymized fashion, creating plausible deniability for the exit node in the event that an interested party attempted to hold an exit node responsible for traffic to an inappropriate resource. If exit nodes opt to enable this feature, data will be logged as such:

Format: Datetime YYYY-MM-DDThh:mm:ssTZD, first 4 and last 3 characters from Base64(AuthToken), destination IP, destination port

Example: 2018-02-16T19:22:30+01:00,dGZk….A==,,443

This data does not allow the originating client user to be identified, as the AuthToken is never logged relative to the IP address, and the AuthToken exists as a secret password between the exit node and client. However, it offers exit nodes plausible deniability to prove that requests to certain hosts were made by client proxies, and not by the exit node themselves.


Translate »