0

In the context of server to server communication, we do TLS/SSL with client certificate authentication. So the communication looks like the following:

service_a on Host_A (as the SSL client) --> service_b on Host_B (as the SSL server)

We have our own PKI infrastructure and organizational CA to issue the certs for service_a and service_b.

Suppose Host_A got compromised (therefore it's private key and the cert of service_a got stolen by the attacker). This attacker quietly set up another EC2 VM Host_C and run (maliciously modified) service_a on Host_C (note: the private key of Host_A is available here on Host_C as well)

How can service_b (along with our own PKI and CA infrastructure) protect or automatically respond this scenario? Is there a way to design such a system?

Improve this question
2
  • Do you assume the ability to automatically detect the compromise of Host_A?
    – user
    Jul 28, 2016 at 18:24
  • No, I don't know if that's doable. Though @sebastian listed several options below in his answer (please see my comment on his answer and I look forward to further suggestion)
    – chen
    Jul 28, 2016 at 21:47

1 Answer 1

Reset to default
1

Theres lots of way to detect this scenario.

1: You can detect the double login since Host_A and Host_C would be logged in at the same time, unless the attacker somehow prevents Host_A from accessing Host_B.

2: You can use the IP of the host to detect if the client IP suddenly switches. I suppose you want to have a API client that communicates with a API endpoint on Host_B, and thus, the client IP should be static.

3: You can "fingerprint" the API client, and if the API client is behaving differently (another useragent or is sending different headers), its considered a compromise.

There might be another sign of tampering, where you can detect something that is not normal. Suppose that your original API client does take a fixed time to perform specific operations. You can then time these actions and if the API client does the action quicker or slower, it can be a sign of attack.

Now to action. To faciliate quicker revocation, I would suggest, in addition to revoking via CRL. As your server can know which certificate is stolen, you can instead configure your API service to not accept logins with that SSL certificate, effectively a "soft revoke". This means that the certificate is blocked immediately, instead of having to wait for the SSL server to reread and parse a CRL into the SSL system.

Improve this answer
2
  • "1. You can detect the double login..." can you elaborate how? Actually there are multiple service_a (using the same cert) running on multiple HOST_A (an auto-scaling group). And the scenario I was thinking here is that one of the machine in this ASG got compromised as above described. "2. You can use the IP of the host..." we don't want to go this route for some reason. "3. You can "fingerprint ..." we don't want to force app guys to do much change (zero app change would be great)
    – chen
    Jul 28, 2016 at 21:54
  • @chen 1: If you know there should only be 3 clients logged in at the same time and there is 4, its something wrong. 3: No change is required on client side. Just store all details that is consistent over each client, and if any unknown client is detected, its a compromise. Even if you have 3 clients with 3 different fingerprints, you can store all fingerprints, and allow any of the 3 fingerprints to be used.
    – sebastian nielsen
    Jul 29, 2016 at 4:53

You must log in to answer this question.

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