18

I'm trying to learn the best way to implement a secure web and e-mail server. Getting SSL certificates is a must, but what happens with the private keys? I've seen that you have to store them on the server but does it imply that my hosting provider will have access to them?

If I would own the hardware, I would simply encrypt the hard drive, but in this cloud/shared/VPS services world it doesn't seem to be possible. Is there a workaround?

  • Of course it is possible to encrypt the data on the virtual disk image the same way as the data on a physical drive but unfortunately as the hosting provider has a full access to the virtualization platform he will be able to extract the encryption key from RAM or CPU registers. --- Such an encryption will just make the attack on the virtual machine harder. --- It is possible that in future CPUs will have security features protecting the virtual machines from the virtualization services provider. (He would be able to access just encrypted data.) In principle this is possible. – pabouk - Ukraine stay strong Sep 10 '15 at 14:03
  • Since you are asking for a workaround, this is by no means official or best practice™. If you manage to find a proxy (for example [CloudFlare](https://www.cloudflare.com "CloudFlare") *), you do not have to place a/the *paid* private key on the machine you are using to host your website. (This is not necessarily a solution for your problem, you still might consider some ideas.) *: I am in no way affiliated with CloudFlare – bessbd Sep 10 '15 at 22:27
  • 4
    ["There is no cloud, just other people's computers"](https://fsfe.org/contribute/spreadtheword.en.html#nocloud) –  Sep 10 '15 at 22:36

3 Answers3

42

Yes, your hosting provider is necessarily able to see your SSL private key, if the fancy takes him to do so. Because that SSL keys is used by his software running on his machines. (This still holds in the case of a hosted virtual machine -- in practice, a malicious host could simply take a snapshot of your running VM and analyse it at his leisure, and you would not know it.)

But note that, for the very same reason, the hosting provider can see all your site contents, i.e. everything that the SSL protects, so the possible exposure of the private key does not substantially change things here.


If you had your own hardware, and the hosting provider simply rented space, power and network bandwidth, then you might hope for some level of privacy and security against the provider. The provider would still have physical access to your hardware (it is located at his premises, not yours) but breaking into a physical machine takes a bit more effort than making a VM snapshot, and, more importantly, is hard to do without leaving physical traces. It really depends on how much the evil hosting provider is intent on doing things discreetly.

For very sensitive machines (e.g. a Certification Authority), you could rent an isolated cage, with padlocks for which you have the key (not the provider), and with in-cage security cameras that continuously send pictures to your remote control facility. That way, you could gain some reasonable assurance that the provider is not trying to physically break into your machines. Of course, this kind of setup tends to be expensive.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 10
    If you were running a CA, I'd hope the private keys for your master certs were kept on computers that were air-gapped from the net, and protected by a lot more than just a padlock and some cameras. – Dan Is Fiddling By Firelight Sep 09 '15 at 14:45
  • 16
    I said "CA", not "root CA". Big difference. – Tom Leek Sep 09 '15 at 14:53
  • Many servers would detect the "Chassis intrusion" and notify you over the network if so configured. – h22 Sep 09 '15 at 18:58
  • 3
    @TomLeek All that means is it's easier to blacklist you if you're compromised (by revoking your CA certificate). Doesn't mean you have any less need for security. – user253751 Sep 09 '15 at 19:51
  • 5
    @immibis In medium to large sized organizations there are various reasons to setup a private CA to establish security and identity within the organization its self. Think, pushing the CA cert to a few hundred employee workstations using group policy. The need for security there is legit, but nothing like what would be expected of a provider owning keys trusted by default in web browsers and operating systems. – trognanders Sep 09 '15 at 22:17
  • @BaileyS I think the key difference there is public vs private; not if a companies internal CA is built from an Intermediate certificate or a private root cert that they distribute via enterprise management tools. If an attacker could abuse it to impersonate sites on the public web it still needs to be very highly protected. A cert that will trigger an untrusted warning on a any computer not owned by my employer not so much; although it still needs a reasonable degree of protection due to spear phishing. – Dan Is Fiddling By Firelight Sep 10 '15 at 13:41
  • @DanNeely That is exactly the point. I was just sharing a use case for having a private certificate. Keeping it safe would be very important for a company since it would allow an attacker to man in the middle any https site accessed by computers that trusted the certificate. Probably no reason to have it online... but still much lower stakes than handling an internet trusted CA certificate (whoever signs/trusts that would require certain security levels and business practices). – trognanders Sep 10 '15 at 14:10
  • `the possible exposure of the private key does not substantially change things` - but it does raise the risk of someone else using you key to impersonate you. – Eborbob Sep 10 '15 at 15:04
  • I worked for a credit reporting company many years ago and this was an issue. In that case we rented a physical, locked server as specified above. It's very expensive and really we just did it for compliance reasons. If you're choosing a reputable host, they have a *reputation* to maintain, and their business could be killed by even RUMORS that they're spying on customer hardware. My recommendation would be to look at the compliance requirements for your industry. It sounds like you're new to this and just being overly cautious. Most of us are in this situation every day with AWS or RS. – Rick Chatham Sep 11 '15 at 17:39
1

In any way, the provider will be able to see it - as any other file on the server. You can only make it harder for him to read it.

The only way to make a file protected from the provider with full access to server where your cloud/shared/VPS services is hosted, is to encrypt that file. However, after encryption, it will be unuseable for your web/mail server.

Vilican
  • 2,703
  • 8
  • 21
  • 35
  • How about using a passphrase for the SSL-key? You need to enter it every time the webserver is restarted. – ott-- Sep 09 '15 at 20:10
  • 1
    Yes, you can use it, but it will be stored (or the decrypted key) in cache, therefore - readable. – Vilican Sep 09 '15 at 20:19
  • 5
    @ott It would need to be stored decrypted in the running server instance, ultimately the key needs to be used. – trognanders Sep 09 '15 at 22:19
1

You could use a hardware security module (HSM), with a non-extractable key. When the server starts, you would unlock the key with a pin through a secure channel. The provider will not see the key nor the pin (there are commercial solutions for this).

Your web server would be the client of the HSM, and the HSM would do the necessary signing or session key decryption operations for it. But while the HSM is unlocked, your ISP could still impersonate your web server to the HSM and get it to sign/decrypt, and so could impersonate your web server towards your clients.

So your ISP could only fake your web server while the HSM is online. To exclude that possibility, you would have to have your own machine, protected from physical tampering and file system access by the ISP, and then, a private key on that machine is almost as good as an HSM.

hobgoblin
  • 19
  • 2
  • 3
    This question isn't about an ISP (Whom simply provides the network connection), but instead a hosting provider (Whom normally provides hardware, space, network connection and, often, software support). I think you may have just used the wrong term though, as your answer still applies. – Chris Murray Sep 10 '15 at 10:06
  • With an HSM, the provider can still sniff your PIN/Password and then use the HSM. Many HSM have a counter that counts how often a key was used and which can't be reset, so if you would check that you would at least know that. The hoster also might be able to use a side-channel attack to get the keys, depending on the HSM this isn't too hard but still magnitudes harder than getting the key from a disk/RAM snapshot. – Josef Sep 10 '15 at 11:25
  • @Josef: The hosting provider can get possession of the credentials which the virtual machine uses to authenticate at the HSM as its client but if the HSM is properly implemented he will not be able to get credentials which the HSM operator uses to unlock the HSM. Anyway as hobgoblin already explained: once the HSM is unlocked (which is necessary during the full operation) the hosting provider can possibly misuse it. --- Manufacturers of HSMs try really hard to minimize possibilities of side channel attacks on the HSMs. In practice reasonable HSMs could be secure at the moment. – pabouk - Ukraine stay strong Sep 10 '15 at 14:27
  • 3
    HSM's are a cost without real operational security. They also add a lot of inflexibility. The H of HSM is immaterial because like you said, the weakest part is the API interface and not the protected storage (which may very well live at the other end of the Galaxy) – DeepSpace101 Sep 10 '15 at 16:20
  • @DeepSpace101: It is important to know what an HSM is good for. An HSM will not prevent fraudulent operations with the private key at the server and at the moment they happen but it can record the misuse (to be able to perform countermeasures later) and it will prevent making a copy of the key (and misuse of it at a different place without your knowledge). ------ You can get at least some flexibility with HSMs if you accept additional costs. (HA, backups, load sharing...) – pabouk - Ukraine stay strong Sep 14 '15 at 14:11
  • @Chris you are right, I should have written the hosting provider, not the ISP. – hobgoblin Oct 22 '19 at 16:37