Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Accepting connection based on client's certificate
Actually, all of this is applicable only to cases, where CA's private key is compromised.
> Actually there is only one sound option, which is to revoke the CA certificate.
Yes, that is what I meant by revoking client certificates, I was meant to say "revoke client certificates along with the CA".
> There is also the situation where the CA's private key is compromised but you don't know that.
This is actually another supporting argument, because if certificates are checked as being generated by CA, then when there appears a certificate that is not, then it actually implies that private key of CA was compromised. Moreover, with the check, there is no harm the attacker could do, by the attempt to connect with unknown (but valid) client certificate he would just bring attention to the fact of compromised CA.
> Sort of, but what you're really saying is that you are no longer using a CA, but instead are placing certificates directly in the configured trust anchor set.
Generally I understand your point. What I want to say is that - if I have a way to add additional layer of "security" (and I'm emphasizing the quotes, I'm aware that has nothing to do with true security) - then I can somehow relax the strict requirements of CA private key security. I can now afford to trust "somehow" less the CA. And when I detect breach I can react and restore full security without disrupting the service.
I think this requirement arises naturally in environments where authentication is ensured using client certificates and update of these certificates is costly or even nearly impossible (which is the worst case, but possible!). 

Jan

On 10/29/19 1:34 PM, Greg Troxel wrote:

Jan Lukavský <je.ik@xxxxxxxxx> writes:


thanks for answer. I'll add a little more context to the
question. Suppose the following situation;

  a) you have your own CA that issues certificates for clients
connecting to mosquitto

  b) each certificate that is generated is securely stored by the CA

This doesn't make sense as certificates are signed and thus don't need
integrity protection.  Generally people don't think they need
confidentiality protection, certainly not at a high level.


  c) common name in client's certificate is used for ACLs

That makes sense.


Now let's consider that our CA's private key is compromised. The would
mean we have two options:

  1) revoke and regenerate all client certificates

Actually there is only one sound option, which is to revoke the CA
certificate.

There is also the situation where the CA's private key is compromised
but you don't know that.


  2) ensure that even if attacker uses the authority's private key and
generates his own certificates, we can detect that

Option 1) might be costly and time consuming, would probably suffer
from service interruptions, etc.

Yes - that's why you need to not do that!


Option 2) does not have this problem, because because we *know*
certificates that were legitimately signed by our CA, we can just drop
connections that look OK, but are actually created using stolen
private key. Of course, this is just a temporary workaround to give
time to fully proceed with option 1) but ensures that there is no time
when attacker can be harmful and that there are no disruptions for
users.

Does that make sense?

Sort of, but what you're really saying is that you are no longer using a
CA, but instead are placing certificates directly in the configured
trust anchor set.

I don't think your situation is all that related to how to do
authorization.   Your Option 2 is about authentication.

Back to the top