3

Is it safe to transfer location data by using TLS with self-signed certificates?

I read a lot of varied discussions on the web which makes me to ask about the subject.

  • 4
    If your client trusts your self-signed certificate, then yes. But why would your client trust your self-signed certificate? It's just like saying, here's a document signed by me saying that I'm who I claim to be. – pri Dec 4 at 12:14
  • Because I'm a client of mine. Just wondering if it's safe to transfer data using TLS that it won't end on the wrong hands. Edit: More likely it is strong enough when doing it through the internet? – Divinar Dec 4 at 12:57
  • 2
    Yeah, it should be fine. Just make sure that your private key remains a secret at all times. – pri Dec 4 at 15:39
  • Safe against what? And what makes location data special? – Bergi Dec 4 at 21:55
7

TLS encryption is obviously strong enough to protect your data. The weakness in this question is the integrity of the keys involved.

Certificates protect the integrity of keys by making sure that no attacker has swapped a legitimate key for a fake key, and is intercepting messages in an Attacker-In-The-Middle attack. The way certificates protect against this is by being signed by a root Certificate Authority that all computers in the communications network agree in advance to trust. By itself, a self-signed certificate has no such integrity, because none of the participating computers knows to trust it.

There are a few ways around this issue. The first (and safest) is to get the key signed by a trustworthy Certificate Authority, instead of being on a self-signed cert. Most CAs charge a fee for a certificate (which can be off-putting). Your DNS provider may offer you a few free certificates as a part of their service. Let's Encrypt offers CA signing to anyone for free, and you can run the whole process through their API. The advantage is that your system's security will be "normal" and your keys will be as protected as any other site; the disadvantage is the small extra effort involved in learning about the process and getting the signed certificate.

Another way is to generate your own custom Root CA. OpenSSL can be used to generate a CA self-signed certificate, which can then be used to sign other certificates, such as your location server's certificate. Google will return plenty of examples of how to do this in just a few calls to openssl. Next, on all the computers where you want to trust your location server's communications, you install the custom Root CA certificate in each system's Trusted Root certificate store. You then use the custom Root CA to sign your location server's keys, and those computers will trust them. This seems easy, because it's just a couple calls to OpenSSL, and installing a new root certificate. And your data and key exchanges are protected. However, the drawbacks are larger than they seem: all the computers that trust your custom CA are now susceptible to spoofing any TLS communications if someone manages to compromise your homemade CA's private key. (This may also be problematic if you don't have the authority to install a new root CA on all the computers involved. For example, your workplace would likely have a security incident if your company PC had your homemade certificate installed on it.) You can mitigate some of this risk by cautiously creating your custom CA, keeping the private key offline on a thumbdrive stored in a safe, etc., but that's a huge amount of work for very little benefit, and nothing can solve the problem of installation on an externally managed computer.

There is a third option: look at the certificate with your eyeballs and make sure it's the same certificate you started with -- every time you use it. While this will work, it only protects one key exchange at a time. A year from now, if you get careless and forget to check the certificate before exchanging data, it's possible an Attacker-In-The-Middle could strike and you wouldn't notice.

A fourth option, which is where I think you were going, is to ignore the integrity of the key exchange entirely, and hope no attacker tries to intercept your communications. Of course, if you're attacked, you'll never know. And if you can live with that risk, why bother encrypting it at all?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.