4

What are the possible defense measures that can be applied to a simple PKI (no intermediate CAs, etc.) used to authenticate clients and servers over TLS on an internal network only?

Certificates issued to clients/servers will have to appropriate TLS Authentication extended key usage set.

Since the CA will be trusted on all devices, I want to make sure that even if the our CA's private key is compromised, the attacker wouldn't be able to create certificates for Internet web sites, or to create trusted signed binaries. In other words, I try to minimize the vulnerabilities that are opened up by the authentication scheme.
Is this possible using X.509 constraints?

So far I've thought of setting the pathLenConstraint to 0, and using the nameConstraints so only certificates issued to private IP addresses should be accepted.

It seems that these measures prevent a lot of misuse, but they still allow the attacker to issue a certificate for e.g. google.com, then—using MITM—impersonate the DNS server and reply with an internal IP address (pathLenConstraint ✓, nameConstraints ✓, intended usage ✘). This scenario would even work with nameConstraints set to the local DNS suffix, since most clients just send another query with the suffix included, if the response is "not found."
Not to mention that I've found no way to prevent a CA (using X.509 constraints) to ever issue certificates used for code signing or timestamping.

Is there any option that I've missed?

Improve this question
2
  • Would designing your own web-app for internal use only make it no longer simple PKI?
    – user49075
    Apr 21, 2015 at 10:54
  • I meant by "simple" that there will be no intermediate CAs, no cross-signing, or anything that is listed in a complex CA system's feature list (e.g. Dogtag ). But yeah, you may be right—this is not a simple scenario. :)
    – KovBal
    Apr 21, 2015 at 11:05

1 Answer 1

Reset to default
1

the only defense against this is using Key Pinning

the problem is that that only works as soon as the client has connected with the web service at least once (to have the proper value for the pin)

and another problem can be that the pin holds for a long time so replacing your certificate or key is not possible while the pin holds (unless you plan ahead and and have a second certificate already pined for the crossover)

After your edit I must conclude that at present there is no way limit such use. there is no solid way to limit a CA certificate to just 1 part of the network. (it's policies that do this. not a technical implementation)

Improve this answer
3
  • As far as I understand the concept, this is not exactly what I'm looking for. Your answer basically says that ALL certificates should be pinned in every single application. But that would mean that most applications should be modified accordingly. There is at least one usage that cannot be altered (Authenticode). I'm not looking for hardening the internal authentication, but to eliminate (or at least harden) to possibility to use this authentication scheme to attack the endpoints.
    – KovBal
    Apr 21, 2015 at 10:14
  • I would pin the Root CA's Public key and 2 Public keys er certificate. it is part of (or becoming part of) the web standards, so Application support is there or should be coming. And what you basically do is you limit the allowed Certificate source list, down from All trusted CA's to a Specific set of Public Keys. It means that you make it means that even if a different CA issues a certificate for your domain it will not work because its not on the allowed list. (this includes MitM certificates) There is no full solution for what you want at the present time I'm afraid. this comes the closest.
    – LvB
    Apr 21, 2015 at 10:23
  • 1
    I think you misunderstood what I want. I edited my question to make it more clear. I want to make sure that our CA is only used to authenticate our internal endpoints and nothing else. This question is not about hardening the internal TLS authentication.
    – KovBal
    Apr 21, 2015 at 10:41

You must log in to answer this question.

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