[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mosquitto-dev] Accepting connection based on client's certificate
|
> But if you revoke the CA certificate, you don't need to revoke the
client's certs. And there could be false client certs, so anything that
relies on the real CA doing revocations is unsound.
Sure. Maybe I'm not able to express myself exactly, but that is what I
meant.
> It seems like you do not believe in the entire concept of a CA
functioning properly. I wonder why you are using a CA in the first place :-)
Disagree. There is difference between having single layer and two layers
of defence (CA and a list of acceptable certificates). If I remove the
CA completely, then:
a) possible attacker can gain access by just modifying some internal
list of certificates (as opposed to having to first obtain the private
key of CA) - more work for attacker means better security because -
after all - all cyber security is based on premise that it is not
possible to have 100% certainty of security, we are just trying to make
attack hard enough to make in not economical or impractical
b) there is impact on system dependencies that govern SLAs - while
running in a private-key-of-CA-is-believed-to-be-secure mode a short
disruption of service that provides list of authorized certificates
does not imply service interruption, because it is not part of critical
infrastructure at that time (client with valid certificate can be let in
with very high degree of certainty). If the list is the only you have
then it become critical part and any disruption of this service
inevitably means disruption for clients (if abandoning security is not
an option)
> Perhaps you should have each device have a self-signed certificate,
and then have a configuration management system to have relying parties
have those specific certificates configured as acceptable. That's almost
like a CA, except with the plus thatt the client doesn't have to obtain
a certificate signed by the CA and the minus that each relying party has
to obtain the list of certificates.
But that is pretty much what I have, with the difference that the CA
brings the benefits mentioned above.
Maybe we have dug too far into details - the principal question is still
the same. Would it be beneficial to incorporate general way of checking
incoming connections with some application-specific logic? And if so
what would be the best way of doing so? The way I have explored is being
able to configure an executable (shell script) that is run for every
incoming connection (and sending MQTT_RC_NOT_AUTHORIZED in case of
failure). That works for my case, but (ideally) I don't want to maintain
own fork of mosquitto. :-)
Jan
On 10/29/19 3:05 PM, Greg Troxel wrote:
Jan Lukavský <je.ik@xxxxxxxxx> writes:
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".
But if you revoke the CA certificate, you don't need to revoke the
client's certs. And there could be false client certs, so anything
that relies on the real CA doing revocations is unsound.
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.
It seems like you do not believe in the entire concept of a CA
functioning properly. I wonder why you are using a CA in the first
place :-)
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.
It's good you realize that the quoted words are a sign of fuzzy
thinking. But seriously, dealing with compromise and revocation is
truly difficult.
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!).
Perhaps you should have each device have a self-signed certificate, and
then have a configuration management system to have relying parties have
those specific certificates configured as acceptable. That's almost
like a CA, except with the plus thatt the client doesn't have to obtain
a certificate signed by the CA and the minus that each relying party has
to obtain the list of certificates.
