4 ms·

The webserver process does not need access to private keys, just access to the encryption service ("TLS offloading").

by xorcist 11y ago

ams6110 11y ago
OK, so if my TLS temination host gets rooted.... I guess the assummption is that host is hardened and less likely to be exploited since it's just doing one well-defined thing? My ignorance may be showing, how would I copmpletely isolate the private keys from the public-facing service? I suppose using an accelerator card would do it?
- wolf550e 11y ago
  No accelerator card needed. You run an "RSA signing server" that accepts connections only from the internal IP of your webserver (or maybe only TLS connections from across the internet but only if the client connecting to it has a client certificate signed by your own self-signed CA, but that depends on topology). It runs a very simple app that accepts requests to sign something and responds with the <something> signed by your RSA private key. The code for this is very minimal and secure. You teach your web server to use this thing during TLS handshake, to sign the ephemeral key exchange. If the web server is hacked, the hackers gain the ability to sign things with your private key, but they don't get the private key itself. They need to hack the "RSA signing service" server for that. They can't stockpile signed ephemeral key exchanges. After you detect the hack, snapshot and kill the hacked server, start a new one from clean backup, they lose the ability to impersonate your site. CloudFlare have a writeup on their service that does this (TLS negotiation by their TLS terminator with only you holding the key): https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...
  - nocarrier 11y ago
    This is an excellent explanation of how private key offloading works, thank you. BTW, you can store private keys in a HSM on your private key server and that's an additional layer of protection, but nobody uses TLS accelerator cards anymore that I'm aware of. You can simply do the relevant crypto on commodity CPUs and still have plenty of throughput.
  - baudehlo 11y ago
    Though I guess what they could do in such a scenario is implement a service which uses the signing server and hope to run undetected. Yes?
    - wolf550e 11y ago
      Yes. My first idea to detect this is keep count of signatures performed on the private key holding server and count of tls handshakes on your webserver.
lmm 11y ago
Does that actually help? If the attacker is running arbitrary code as the webserver, they can use the webserver's access to the service to MITM anyone trying to connect to you.

The webserver process does not need access to private keys, just access to the encryption service ("TLS offloading").

by xorcist 11y ago

The webserver process does not need access to private keys, just access to the encryption service ("TLS offloading").

OK, so if my TLS temination host gets rooted.... I guess the assummption is that host is hardened and less likely to be exploited since it's just doing one well-defined thing? My ignorance may be showing, how would I copmpletely isolate the private keys from the public-facing service? I suppose using an accelerator card would do it?

wolf550e 11y ago
No accelerator card needed. You run an "RSA signing server" that accepts connections only from the internal IP of your webserver (or maybe only TLS connections from across the internet but only if the client connecting to it has a client certificate signed by your own self-signed CA, but that depends on topology). It runs a very simple app that accepts requests to sign something and responds with the <something> signed by your RSA private key. The code for this is very minimal and secure. You teach your web server to use this thing during TLS handshake, to sign the ephemeral key exchange. If the web server is hacked, the hackers gain the ability to sign things with your private key, but they don't get the private key itself. They need to hack the "RSA signing service" server for that. They can't stockpile signed ephemeral key exchanges. After you detect the hack, snapshot and kill the hacked server, start a new one from clean backup, they lose the ability to impersonate your site. CloudFlare have a writeup on their service that does this (TLS negotiation by their TLS terminator with only you holding the key): https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/ https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...
- nocarrier 11y ago
  This is an excellent explanation of how private key offloading works, thank you. BTW, you can store private keys in a HSM on your private key server and that's an additional layer of protection, but nobody uses TLS accelerator cards anymore that I'm aware of. You can simply do the relevant crypto on commodity CPUs and still have plenty of throughput.
- baudehlo 11y ago
  Though I guess what they could do in such a scenario is implement a service which uses the signing server and hope to run undetected. Yes?
  - wolf550e 11y ago
    Yes. My first idea to detect this is keep count of signatures performed on the private key holding server and count of tls handshakes on your webserver.

lmm 11y ago

Does that actually help? If the attacker is running arbitrary code as the webserver, they can use the webserver's access to the service to MITM anyone trying to connect to you.