leoluk
commented
2 months ago Sad upstream issue: https://github.com/etcd-io/etcd/issues/9276
I agree that it is a useless check that adds no security.
Open lorenz opened 2 months ago
leoluk
commented
2 months ago Sad upstream issue: https://github.com/etcd-io/etcd/issues/9276
I agree that it is a useless check that adds no security.
q3k
commented
2 months ago This seems to be a hack for people who have deployed a system reusing the same CA certificate for more than just etcd peer clients (eg. same CA certificate for clients, or even for non-etcd uage). I assume it's also argumented by the fact that if the server/client relationship was flipped around (which happens for member connectivity) similar checks would be peformed.
But yeah, this is somewhat sad and we should probably spend some time reviewing the etcd code for more weirdness like this.
etcd has this weird extra client certificate verification step which looks up the PTR record of the connecting IP and checks if it is in the client certificate SAN. This is a terrible idea for multiple reasons including that it can suddenly break consensus if that PTR record gets answered externally while also not providing any security because DNS is untrusted and any MITM can easily fake whatever PTR they need.