11

I'm doing an integration with a system that has a self-signed certificate. For initial development, we choose to ignore the certificate checking to bypass some errors:

Exception in thread "main" javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

because we first need to understand how to add the certificate using the Java keytool on a docker environment.

But, my question is: what is the advantage in that case to import a self-signed certificate as a "Trusted Certificate" when I could just ignore it?

usr-local-ΕΨΗΕΛΩΝ
  • 5,310
  • 2
  • 17
  • 35
Dherik
  • 213
  • 2
  • 7
  • You should read Peter Gutmann's *[Engineering Security](http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf)* book. There are two or three chapters dedicated to the business of PKI. Self-signed certificates are fine, and often better than warez you get from PKI vending machines. The web security model is a whole 'nother can of worms, and you should avoid it if possible. –  Jul 02 '19 at 11:20
  • I think that a statement like "_the web security model is a whole 'nother can of worms, and you should avoid it if possible_" needs references. But I nonetheless agree with your advice about using self-signed certificates when it is possible. – jjmontes Jul 02 '19 at 15:51
  • If you can transport the certificate or at least it’s fingerprint over a secure channel you have a very reliable way to be able to recognize impersonation attacks. In fact the trust level might be much higher than trusting any of a hundred public CAs to not do their work correctly. So a Self signed (or privately signed) certificate is not only a convenience hack but might add additional protection (but also more work) – eckes Jul 02 '19 at 18:22
  • "For initial development" ==> I think it's a good idea to reduce the complexity and effort of work by relaxing certain constraints. It's, however, extremely important that you **track** with //TODOs or Jira tickets that your software needs a change before going live. While you and your fellow developers build the application, one of the team may focus on adding the certificate to the trust store, which is a joke, without slowing the development process. I would also add a software engineering advice: please implement code that will turn SSL validation on or off based on a *switchable property* – usr-local-ΕΨΗΕΛΩΝ Jul 03 '19 at 07:58
  • (Continued) so that you disable certificate validation only under exceptional circumstances like developing on your machine or test network and only when needed. – usr-local-ΕΨΗΕΛΩΝ Jul 03 '19 at 07:59

4 Answers4

25

If it's an official service you are integrating with the provider should really have a valid, publicly signed certificate installed for the sake of security.

Assuming that you need to continue on with your provider using a self signed certificate, the big difference between ignoring the certificate and adding it as trusted is the following scenario. This ues DNS poisoning as an example of a man in the middle attack.

Take the following example:

  • api.example.com has a self signed cert with thumbprint XXX listening on the IP 5.5.5.5.
  • Adding it to your trust store makes your system expect the thumbprint to be XXX when connecting
  • If someone was able to poison your DNS - make api.example.com resolve to 6.6.6.6 - the thumbprint would be YYY.
  • By adding the cert to your store your product would refuse to connect to the malicious site.
  • By disabling the check entirely, your product would happily connect to the malicious api.example.com at 6.6.6.6.
Tim Brigham
  • 3,762
  • 3
  • 29
  • 35
  • To be fair, it depends what the system is. If it's self-hosted, it's not really fair to expect the service provider to ship certs with their program; they don't know what domain it'll be hosted on. If it's externally hosted, though, I agree -- it's weird that they don't have a proper, CA-granted cert. – Nic Jul 01 '19 at 22:14
  • 11
    Not just DNS poisoning, any sort of MitM would be included as well, however that M manages to insert himself into the M… – deceze Jul 02 '19 at 05:01
  • 1
    @NicHartley If it's self-hosted, I expect the vendor to provide a way to install a custom certificate. – chrylis -cautiouslyoptimistic- Jul 02 '19 at 05:03
  • @chrylis That's... what I was trying to say. That the system itself just has a slot to put a cert in, and whoever _set up_ the system was doing it wrong, not the system's designers. – Nic Jul 02 '19 at 05:08
  • 2
    @deceze fair point, I just used it as a specific example. – Tim Brigham Jul 02 '19 at 11:28
  • You nowhere explain why using a certificate signed by organisation A is magically worse than the certificate signed by organisation V. There's absolutely nothing special about certificates signed by Verisign compared to a proper self-signed certificate. Sure you have to trust the root cert, but that's trivial to set up (and depending on your security settings, it's quite possible that not all big public CAs would be trusted either in a given environment) – Voo Jul 02 '19 at 18:55
  • @voo, that wasn't the bread and butter of my answer. The idea here wasn't it to explain the best practices. And no, a self signed cert isn't an equal. You have no guaranteed validity period, no revocation checking, and no guarantee of the key size. These are all guaranteed by a reputable CA. – Tim Brigham Jul 02 '19 at 22:26
  • @Tim And can all be guaranteed by a competent private CA just as well (why would there be no revocation checking for private CAs?). Although the trust you place in public CAs seems misplaced (Symantec still signed sha1 1024 bit keys in 2013, so much for guaranteed key sizes..). We are talking about the same companies that regularly sign certificates they have no right to, or even lose their keys altogether? – Voo Jul 03 '19 at 03:58
  • @Voo, no argument that they *can* just not an actual *guarantee*. I've never seen a contract written up for someone providing a self signed certificate outlining certificate management policies. – Tim Brigham Jul 03 '19 at 13:16
  • DANE, with DNS TLSA records, exactly allow one domain owner to advertise, per service under its domain which certificate and/or CA are to be expected to connect. – Patrick Mevzek Jul 03 '19 at 15:12
  • @PatrickMevzek, thanks for that. I've never looked at the option to specify a specific hash before. Good reading. – Tim Brigham Jul 03 '19 at 16:02
16

By importing a known good self-signed certificate where the private key is unique and not compromised, the connection is just as safe as a full global CA PKI signed certificate. Those are after all also simply stored and trusted at some point.

The reason to get a PKI CA signed cert is one of practicality more than security; if you have to trust a self-signed certificate on many clients, that can be a lot of work. And doing key rotation almost exponentially increases that work.

If you control the server and client, like during development, and you don’t have the skill or resources to setup a private CA, then adding a specific self-signed certificate to a trust store is not so bad. Accepting any certificate is bad, never do that.

John Keates
  • 820
  • 4
  • 7
  • 2
    Key rotation has turned out to be mostly useless from a security point of view. In fact it appears to be harmful. In practice key continuity is a much better security property. –  Jul 02 '19 at 11:16
  • @jww "Key rotation has turned out to be mostly useless from a security point of view." Can you point me to something that elaborates on this? Thanks. – JimmyJames Jul 02 '19 at 14:54
  • Key rotation has no relation to password change enforcement, if that’s what you’re getting at – John Keates Jul 02 '19 at 15:06
  • @jww I'd be interested about sources as well. There's good reasons to use key rotation (e.g. you limit the amount of data that is exposed if a key ends up being exposed) and I haven't experienced any downsides either. I assume it's to do with the fact that short rotations mean the intermediate CA won't be as well protected as it would be otherwise? – Voo Jul 02 '19 at 18:58
  • See Peter Gutmann's *[Engineering Security](http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf)*. He dedicates an entire section on key continuity. He also offers a couple chapters on PKI and its numerous problems. Key continuity is how [DigiNotar](https://en.wikipedia.org/wiki/DigiNotar) was discovered. You might also be interested in the web security model, and how interception is a valid use case. –  Jul 02 '19 at 19:00
3

If you ignore the certificate check, anyone who can gain the man-in-the-middle position (with the ability to modify traffic) between you and the other system can read/modify the plain-text traffic. An attacker will simply break the TLS/SSL tunnel by starting his own TLS server using his self-signed certificate, route your traffic to it, decrypt it, and proxy it to the real server. There are many tools which make this attack pretty easy, for instance, mitmproxy for HTTPS or stunnel in general for TLS/SSL.

An attack can get into the man-in-the-middle position in many different ways. Thus, it is tough to completely rule out, that there is no way for an attacker to gain this position even if you're a network security expert.

If there is no way to replace the self-signed certificate with a publicly signed certificate, you can trust self-signed the certificate manually by adding it to a Java keystore using keytool and trust this store. This is sometimes called Certificate or Public Key Pinning

sven.to
  • 586
  • 3
  • 5
1

Certificates are the way that the signer can vouch for the signee. If you trust the signer, then you can trust the certificate and the signed public key. If you trust the signee, you can ignore the certificate.

In more real world terms:

Example 1: Cindy Certificateauthority is very well known. Everyone knows Cindy. Cindy has a really good reputation for verifying who people really are before she introduces them to other people. Someone claims to be Pablo Pubkey - a well known and trustworthy salesman - wants to sell you something. Cindy introduces you to this person and says that he's Pablo. You trust Cindy, so you believe that the person is Pablo, and so you decide to give Pablo your credit card number and buy stuff.

Example 2: You grew up with Freddy Friend since you were a child. You know who Freddy is - you met him in kindergarten and seen him become an adult alongside you. Freddy is also a salesman. If you want to talk to Freddy, you just go find Freddy - you don't need anyone to introduce you to him.

In the first example, you relied on a certificate authority whom you trust to tell you who owns a particular public key. In the second example, you had direct trust in the public key and didn't need a third party to tell you who owns it - for example, your software may issue public keys to its users and associate those public keys in your software's database. This second example is exactly the same when you have a self signed certificate and an unsigned certificate.

atk
  • 2,156
  • 14
  • 15