Clients Do Not Authenticate Provider Certificates

[xloem]

Assign the support label to any support escalation issues

Describe the bug The current client peer certificate verification code completely ignores the on-chain certificate and public key data, allowing a network adversary to provide a false certificate to any client.

To Reproduce Note: I have not tested this, but it looks like you could generate a certificate with matching owner address and serial number to any active one on-chain, and offer it to a client in a machine-in-the-middle attack, and it would be accepted because the certificate is not sufficiently verified. All communications could be logged, and fake responses provided.

Expected behavior It looks like the code should retrieve the certificate and public key fields from the QueryCertificatesResponse object and compare them with the data from the network here.

Additional context I'm a crazy old software developer and I spammed a mailing list about this issue.

[troian]

@xloem thank you for opening this up.

• first of all, each certificate is being validated against various boundaries, including owner address during certificate creation on the chain
• provider fetches on-chain certificates during TLS handshake

would be good to provide steps to reproduce the issue.

[xloem]

Just found your reply. You’re saying that if this is real, you would like a demonstration of code that can illegitimately falsify client or server connections? (It’s psychologically easier to try to make something like this if asked by the developers.)

The concern is where in the code the network certificate is fully compared with the on-chain certificate.

[troian]

What I'm trying to say is: there very well can be a bug, but we don't have the ability to look into someone's mind a see the complete picture you're trying to describe.

If you check the link above, then follow a path that leads to the provider implementation of the TLS handshake, the certificate validation could be found, and it indeed compares client's certificate to one on-chain.

[xloem]

My understanding is the link you posted (which I followed) regards certificate creation, not comparison during handshake. My understanding is I posted a link to the verification handshake, and to a mailing list email where I annotated this verification. I did not find a place where the certificate is compared, only small attributes.

Regarding mind reading, I also didn't find this on the server side, but I didn't mention it as it would be incredibly severe, and I usually miss things.

Smells funny, notably that we're not clearly addressing if there's an issue. I'll try to demonstrate it if or when I find time, and just assume akash is completely insecure until I do (sorry about that, please simply link to the certificate comparison in the code).

[xloem]

To be more clear here, if the certificate is not compared with the on-chain one via fingerprint, public key, signature, or complete copy, then an attacker can falsify one end of the connection by producing their own certificate in the same manner as the certificate creation code.

On the server side, they would do this by mutating the client's domain name lookup or packet routing, and offering a malicious server for them to connect to instead. On the client side, they would do this by simply connecting to the server with their fake certificate.

If the certificate or public key is compared with the one on-chain, the effort fails, otherwise it could succeed.

[xloem]

If you check the link above, then follow a path that leads to the provider implementation of the TLS handshake, the certificate validation could be found, and it indeed compares client's certificate to one on-chain.

To clarify further, I don't know what you mean by "provider implementation of the TLS handshake" and I don't see something like that in your link.