## Can a VPN carry out a Man-In-The-Middle Attack?

If the reader needs to ask this question, then I’d suggest that the question should first be translated into a similar question, which the reader more-probably needs the answer to:

‘Can software which claims to be a VPN, intercept the user’s data or carry out a MITM attack?’ A way in which some software can attack its user is by misleading him or her, about what its nature is. In order to assess this question quickly, I’d ask two more questions about the software:

• We know that Windows, Mac and Linux computers have a large variety of installed libraries, that make up the core of how each O/S works, which under Windows are .DLL-Files, and which under Linux consist finally of .SO-Files. Does this software replace any of those existing libraries with its own versions?
• Does this software install anything, such as Browser Extensions, which may change the way the browser behaves?

If the answer to either of these two questions was ‘Yes’, then in fact, this software has an opportunity to perform a MITM.

If the answer to both questions was firmly ‘No’, then the possibility is more likely, that this software really is ‘just a VPN’, in which case it should not be able to perform a MITM.

Why? Because, as long as we are connecting to a Website the URL of which begins with ‘httpS://’, and not ‘http://’, what a healthy browser will do is to encrypt its traffic to and from the site, using a public key, for which only the intended site has the private key, needed for decrypting the exchanged data. This is already being done by mainstream browsers, on the assumption that one or more of the connecting pieces of the Internet are insecure or untrustworthy. In the case where a link in this chain actually performs its own encryption, well that’s just another insecure link according to the way data is secured.

Data can be encrypted more than once, and, assuming that different encryption keys are being used each time, taking data which was already encrypted, and encrypting it again, does not by itself compromise the security of the data. The resulting stream just needs to be decrypted twice again, each time using the appropriate keys, each of which is held by a different party, to translate the data back into its clear-text form, in this case finally on the Web-server.

Therefore, VPN software operating as it should, ends up passing through any data that has been encrypted using a shared secret between the browser and the server, as though this data just consisted of random bytes. But, a VPN will add a layer of encryption to it. It can also be said conversely, that, given the encryption of the VPN, the browser adds its layer of encryption.

But what of software that confuses its users into installing special browser extensions, or library-overrides? Well, such software could have as its special behaviour, to cause the client to bypass its own encryption, only applying whatever encryption the so-called VPN may apply, and also doing what any client could do, which is, to connect to the server using encryption that exists between the VPN and the server, as a proxy. A computer which has been modified in this way is essentially hacked.

Dirk

## How NOT To Install Self-Signed Certs On Our Plex Server

I have just installed a Plex server, on the host-machine I have on my LAN, that host-machine being named ‘Phoenix’. The purpose of this server is to allow me to access Media Files – i.e. Movies and Photos – Not Just from anyplace within my LAN, but from any place outside my LAN as well, which only I will have access to – as we don’t share our Plex passwords with friends.

Some people might wonder why this is useful to me, especially since Plex is a paid-for service, and since I already have a VPN. And the reason is simply the fact, that to access certain resources on my LAN by way of the VPN, can be slow and cumbersome. It might work for a Samba share, just to fetch a file, but if the objective was to watch a movie which I own, and the original format of which I did pay for, then to leave my tablet with a modified network configuration, and logged in to my VPN, for the duration of the entire movie, would become quite impractical. So Plex was my chosen answer.

One problem which some Plex users could run in to, is the idea that when outside their LAN, they first contact a Web-server, which then redirects them to their private IP address. This idea can lead to another idea, which would be that the following connection from their client-program to their Home LAN is not secure, for which reason some Plex users might want to set up an SSL / TLS certificate to secure that second, redirected connection.

The problem with that last part is, that if our Plex server version is reasonably up-to-date, then we don’t need to do this, because Plex has already done so. There exist several tutorials on the Web, one of which explains to us how to set up a self-signed cert, and another which explains to us how Plex on the Web has already got us covered.

My misfortune last night was the fact that I stumbled on these tutorials, roughly in the order in which they occur above: First, to try to install a self-signed cert, then to learn that Plex already has a system in place with “DigiCert”.

The way in which Plex is intended to work with basic users like me, we all have URLs with the Plex site, that run roughly like so:

*.625d406a00ac415b978ddb368c0d1289.plex.direct

1. The user first connects to the Web-server-URL, for which Plex inc. has a certificate, which in turn encrypts communication from that point on.
2. The URL is then not just redirected, but actually rebound, with the IP address of our Home LAN, so that the same cert encrypts the media-flow to our personal server.

What this means is that for most small-scale uses, we don’t need to acquire our own certificate, to secure a direct connection to our LAN. We can just configure our server like so:

If we feel that we need greater security, we can change the settings to “Required”, meaning that all connections to our Plex server, except from the same computer (from ‘localhost’), and except from within our LAN, will need to be secure in order to proceed. And then most of us still won’t have to fill in any of the fields below, to set up a custom cert.

But there is a disadvantage to settings ‘Secure Connection’ to ‘Required’. The simple usage-scenarios can be given, that we want to connect to our media-server using an app that doesn’t support TLS, or through the ‘Plex Web’ site, but from within our own LAN. What Plex Web will try to do, is to rebind the IP-address to the IP-address  which our server has on the WAN, and to give us a secure connection that way – even though we’re connecting to a place on our own LAN!

This can easily fail, because It can go against router policy, to rebind IP addresses to our own LAN. It can also go against browser policies, in the form of ‘Application Boundary Security’, where an external site is not supposed to gain access to resources on our LAN…

But as it stands, each of my Android clients was already set up by default, to ‘Allow Insecure Connections: Never’, my Roku works, and there is no need to use Plex Web from home.

I suppose the reader might wonder, what would happen if indeed, he was to set up a Custom Certificate for his Plex server at home…