Security

Can I set up SSL certificates without distributing the private key to clients?

ctaf
Contributor

Hi,

I would like to set up SSL communication between UF and Indexers but when I check the docs and wiki, I see that I have to either:
1- Copy the Indexer certificate WITH the its private key onto UFs (see part 3 of https://wiki.splunk.com/Community:Splunk2Splunk_SSL_3rdPartyCA)
2- Or I can create a client certificate besides the Indexer certificate (see https://docs.splunk.com/Documentation/Splunk/7.0.1/Security/ConfigureSplunkforwardingtousesignedcert...)

The second option seems more secure because I would not have to copy the Indexer private key onto UFs. But this also means that a private key (the UF's) is available on the client... This is not really secure because the client is always more vulnerable than a server. The best way I can think of is to keep only one private key, and keep it on the Indexer. Is it doable?

If not, what happens if a "hacker" gets the UF private key (second option)? Can he read the communication and alter the communication?

Thanks

0 Karma
1 Solution

FrankVl
Ultra Champion
  1. Step 3 only mentions to copy the Indexer's certificate and CA certificate to the forwarder. This is such that the forwarder trusts this certificate (chain). In the basic setup the forwarder does not need its own certificate and key.
  2. Using client certificates (and configuring the indexers with requireClientCert=true) adds additional security, as it enables the indexers to confirm that the forwarder is an authentic forwarder and not some attacker trying to for instance swamp the system with useless data.

If you set up both server and client certificates (also called mutual authentication) and an attacker were to steal a client cert and key, the attacker could impersonate an authentic forwarder and connect to the indexers to send data. Stealing a client key does not allow an attacker to read information between forwarders and indexers (unless you indeed use the same key everywhere).

View solution in original post

FrankVl
Ultra Champion
  1. Step 3 only mentions to copy the Indexer's certificate and CA certificate to the forwarder. This is such that the forwarder trusts this certificate (chain). In the basic setup the forwarder does not need its own certificate and key.
  2. Using client certificates (and configuring the indexers with requireClientCert=true) adds additional security, as it enables the indexers to confirm that the forwarder is an authentic forwarder and not some attacker trying to for instance swamp the system with useless data.

If you set up both server and client certificates (also called mutual authentication) and an attacker were to steal a client cert and key, the attacker could impersonate an authentic forwarder and connect to the indexers to send data. Stealing a client key does not allow an attacker to read information between forwarders and indexers (unless you indeed use the same key everywhere).

ctaf
Contributor

Thanks! It is more clear now but still a couple of doubts:
1) Are you sure? They are mentionning to copy myServerCertificate.pem which they earlier built by doing:
# cat myServerPublicCertificate.pem myServerPrivateKey.key myCAPublicCertificate.pem > myServerCertificate.pem

2) Just to be sure, when you say "unless you indeed use the same key everywhere", you are talking about the client private key? I have thousands of clients, it is very hard for me to maintain thousands of certificates. So if I choose the same key/certificate pair for every client, an attacker could read the data? He does not need the private key of the indexer to read it?

0 Karma

FrankVl
Ultra Champion
  1. Good point, didn't notice they included the private key in the certificate.pem file. Technically there is no need for the client to have the private key of the server certificate. This is against the whole concept of such private/public key cryptography. So it seems to me that those instructions are mistaken. It is also strange that they suggest to copy myServerCertificate.pem and the CA public certificate myCAPublicCertificate.pem, while myServerCertificate.pem already includes myCAPublicCertificate.pem. So I think the instructions in step 3 should read: copy the server public certificate myServerPublicCertificate.pem and the CA public certificate myCAPublicCertificate.pem into $SPLUNK_HOME/etc/certs/ on the forwarders.

Also, this line from step one clearly shows that the person writing that text has no proper understanding of how public/private key crypto works:
" This key will be used to encrypt the outgoing data on any Splunk instance where you install it as part of the server certificate. "
The client uses the server's public key to encrypt, upon which the server uses its private key to decrypt. Not the other way around.

I guess this warning at the top of the page (if you're logged in) is there for a reason: "Much of the content on this site is quite old, should be consumed with caution, and may be removed in the near future."

  1. With "everywhere" I meant using the same key on server and client. As long as you use a different key on the server and only the client key is compromised, that only allows impersonation, it doesn't break confidentiality of the communication between other forwarders and the indexer.

ctaf
Contributor

Ok Thank you very much! I will do some testing now 🙂

0 Karma

jworthington_sp
Splunk Employee
Splunk Employee

Hi there,

I write the docs for the securing spunk manual. I wanted to pop in to say that the community article you are looking at is not really correct for version 6.4 or later.

https://docs.splunk.com/Documentation/Splunk/7.0.1/Security/ConfigureSplunkforwardingtousesignedcert... is definitely the most up to date topic.

And feel free to review that topic as well, I'm always looking for ways to improve the docs!

Cheers,
Jennifer

0 Karma
Get Updates on the Splunk Community!

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

Splunk is officially part of Cisco

Revolutionizing how our customers build resilience across their entire digital footprint.   Splunk ...

Splunk APM & RUM | Planned Maintenance March 26 - March 28, 2024

There will be planned maintenance for Splunk APM and RUM between March 26, 2024 and March 28, 2024 as ...