1

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. – immibis Apr 19 '15 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. – David Mulder Apr 19 '15 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. – immibis Apr 19 '15 at 11:30
1

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? – David Mulder Apr 19 '15 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. – Arran Schlosberg Apr 19 '15 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? – David Mulder Apr 19 '15 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. – Arran Schlosberg Apr 19 '15 at 22:56
1

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. – David Mulder Apr 20 '15 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. – Arran Schlosberg Apr 20 '15 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 '15 at 8:44

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.