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:

plex_2

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…

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

Bluetooth Dissed

One argument I hear often from laypeople, is that they don’t like Bluetooth, because at the user-level, Bluetooth Pairing is hard.

People who are knowledgeable in Computing understand, that every time we create a Bluetooth Pairing, our devices are establishing a communications channel, which is as secure as the authors of Bluetooth can make it, due to Advanced Encryption. So we see that there is a potential benefit to this.

For example, in the case of a keyboard which is connected to a tablet – which means that a BT session is underway – it can happen at any time, that we type in our password to unlock the tablet, or to unlock any of our accounts on the Internet. That could be made a generic wireless link which is extremely easy to set up. But then, since we’re always weary of an eavesdropper, the link would be of an ideal format, to steal all our passwords from us through direct exploitation.

But because we’re using Bluetooth, in fact it’s an encrypted link. So even if the ones and zeroes that make up a communication were intercepted, the hypothetical eavesdropper would still not be able to exploit them.

And so I can empathize with knowledgeable people, who feel that the added difficulty in establishing a Bluetooth Pairing, is well worth the effort.

Continue reading Bluetooth Dissed

Routine OpenVPN Test Unsuccessful Today

My computer ‘Phoenix’ does not just act as my Web-server. It also hosts a secure VPN which I own on my own LAN, and that uses the OpenVPN protocol.

Because certain software receives updates from time to time, I also test this VPN from outside my LAN from time to time. To do that, I have typically walked to a certain WiFi Hot-Spot and tested it from there.

However, when I tried this today, I was not able to establish a secure connection to my OpenVPN server at home. The message which I was getting, on my client, was

‘‘

Which finally led to the message

‘‘

And in my server log the messages were:

 


Mon Jan 30 13:16:38 2017 70.24.177.137:61346 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Jan 30 13:16:38 2017 70.24.177.137:61346 TLS Error: TLS handshake failed


 

I understand what these error messages mean. When certain Internet traffic is being routed or -ed, it is routine that the return address of individual packets is changed. However, in this case it means that the router policies of the WiFi Hot-Spot I have been able to use in the past has changed, so that I will no longer be allowed to connect to my home VPN in this way.

I find this to be a shame.

(Edit 01/31/2017 : As of the next day, I was able to turn this result into a full success. )

This does not mean that anything is necessarily wrong with the IP address subnet of the VPN I have created on my LAN, because while connecting to the server from outside, the client never gets to create a virtual ‘‘ device, which might have an unsupported subnet if it was created. The process just never passes the -phase, which is meant to create a secure connection between the client and server.

(Edit 01/31/2017 : Since the latest news states that I was able to access my VPN and its member computers, this confirms instead, that the IP Address Subnet of the is fully functional, that remaining 192.168.2.129 / 255.255.255.192 . )

So in the future, I will not be using this WiFi Hot-Spot anymore, especially since their policy could be altered further, into telling the client that a secure connection exists, with properly-routed packets, but a Man-In-The-Middle Attack could be unleashed. And in that case, it would be unfortunate if the client did not possess the logic to conclude, that a secure connection was not established.

Dirk

BTW: When somebody mounts a man-In-The-Middle Attack against a connection secured via Public-Key Cryptography, the latter being based on the premise that any public key which was signed by an arbitrary Certificate Authority, must be a valid key, one trick which does get used, is to respond to a connecting client by mimicking a known public key that is already in-use. So an MiM attack method that is known, will effectively throw the packets back at the client seeking to connect, which some client has already proven, must have legitimate keys. Only, the trick would be to modify the packets somewhat, so that instead of only talking to himself, the client unknowingly ends up talking to the attacker – in a way the attacker can decipher.