Lets consider the following setup:

One has a decentralized network of servers. A single root certificate has been distributed to all servers which has been positively checked as authentic and untampered by each server owner using checksums distributed all over the internet. Each server connects to a centralized server (secured by the root certificate) over HTTPS and requests the signing of a certificate for itself, which is provided as long as it proves ownership of its domain. From that point on the server uses that certificate to identify itself and communicate over the network. Certificate pinning is used by all servers in the network and a new certificate is only accepted after the green light of the local server owner.

The problems this tries to solve:

  • Secure the network against MITM attacks and eavesdropping, as my understanding is that the only real alternative consists of a manual exchange of keys between each server pair (or in WoT construction, which I deem similarly weak).
  • The fact that requesting every server owner to pay for SSL certificates is unrealistic.

What would the main be weaknesses of such a setup in light of the problems it tries to solve? And what I am especially curious about is whether temporary full access to the centralized server infrastructure would theoretically allow long-term eavesdropping on and/or tamperering of communications between servers.

  • "What are the weaknesses of this system?" seems very broad. Apr 19, 2015 at 10:59
  • @immibis After re-reading my question I realized the question was indeed broader than I intended it to be. My bad. Edited it now. Apr 19, 2015 at 11:18
  • I don't really use security.se much (I'm more active on SO and just happened to see this question) so I'm not really familiar with what is normal for security.se questions, btw. Apr 19, 2015 at 11:30

2 Answers 2


In light of the broad question I will concentrate on answering your more specific one regarding full access to the centralised server. I'll refer to said server as a CA because this is essentially what you are describing.

TL; DR it depends

Let's presume that full access means knowledge of the CA's private key. This may not always be the case if we consider HSMs as against a simple server, but that makes this a boring question. Such access to the private key will then allow an adversary to sign arbitrary certificates which are automatically trusted by all network members regardless of their false claims of ownership.

Eavesdropping implies passive listening on the network. Even with CA compromise only ciphertext is visible to the adversary as individual servers have never published anything beyond their own public keys. They are assured of communications with the true owner (whomever that may be) of a specific public key; being passive implies that there is no such change of end-point keys.

An active involvement as a MITM would allow both eavesdropping and tampering through impersonation.

As a side point; in the case of (EC)DHE usage, even knowledge of individual server private keys would be protected against passive eavesdropping as a MITM would have to intervene to establish shared secrets with each party.

  • 1
    Wouldn't relatively strict certificate pinning mean that impersonation would be noticed? Or am I misunderstanding certificate pinning? Apr 19, 2015 at 11:40
  • No you're understanding it correctly. It is however vulnerable in that it is based in "trust on first use" which, although requiring complete tampering for all communications, is a theoretical vulnerability. If you were to have "perfect" pinning then you would be in the situation of the manual key exchange that your question describes. Apr 19, 2015 at 11:43
  • But am I correct in my understanding that as long as the root certificate is successfully distributed and checked manually, no network server ever needs a certificate re-issued after t=0 (unrealistic, but humor me O:) ) and the CA's private key is leaked at t=1 eavesdropping and tampering of data could none the less not happen given 'absolute' certificate pinning? Apr 19, 2015 at 11:53
  • Assuming that individual server keys aren't compromised then a central compromise just results in MITM issues. 'Absolute' pinning (i.e. some trusted means of distributing all public keys to all parties) obviates the need for the CA in the first place as they act as the trusted means of distribution. Apr 19, 2015 at 22:56

This setup is trying to match domains and ssl keys. However, I would start by questioning what are ‘domains’ here why are they important.

Could the domain simply be a hash of the ssl key? That way you no longer need the CA.

How are the domains assigned? If they are centrally assigned, could the ssl signing be simply provided as one step of the domain registrarion?

Also, if we are dealing with domains like those we have in the internet, they already require paying. It's not that unrealistic for server owners to pay for SSL certificates, it could even be included in the domain registration taxes. There are also a few CAs providing SSL certs for free nowadays. That SSL certificate often have abusive prices is not a requisite of the schema.

  • Domains can be bought for as little as $4 per year (depending on which top level domain you want), SSL certificates would add to that $8 per year. It's not a significant cost, but if every server installation is required to have a domain and those are set up by normal users it does become significant. Apr 20, 2015 at 9:14
  • Do the domains need to be human-friendly? Angel's idea regarding a hash of the SSL key is quite good if they're purely for identification. You can purchase a single parent domain, issue sub domains as base64 (less special characters) encoding of public keys (like HPKP), and ensure that DNSSEC is properly implemented. Apr 20, 2015 at 9:58
  • @DavidMulder, if you used StartSSL or CAcert you can have SSL for free (while still not having to rely on a private CA).
    – Ángel
    Apr 21, 2015 at 8:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .