#TLS question: when using mutual authentication (ie. server and client certs), is it possible for an MITM to spoof the client certificate when the server doesn't know the correct fingerprint yet, while presenting the correct server certificate to the client in the same connection, so without the client knowing anything is wrong?

@joepie91 what does "server doesn't know the correct fingerprint yet" mean, and how is this mutual authentication then?

@oilheap This is part of a design for a pairing mechanism; there is a point in the process where a client connects and presents a client certificate, and the server will see this certificate being presented, but does not yet know what the client certificate is *supposed* to be, but the client *does* know the server certificate. Essentially it's a mutual authentication process in every way except for the server not knowing whether to approve or reject the client certificate yet.

(This doesn't involve any browsers or anything, this is completely custom and just uses TLS' mechanisms)

@oilheap Er, to clarify, with "completely custom" I mean the way in which this is being used and applied, essentially using OpenSSL as a library; not that the cryptographic implementation *itself* is custom

@joepie91 if the client knows the correct server cert and an attacker can spoof it, they have the private key which means you have worse issues

if you just mean that an attacker runs the registration/pairing with their own cert the server can’t tell that anything is wrong without already having verified the key via another channel

@joepie91 it doesn’t appear so, I checked the spec quickly and the handshake flow for this involves a “CertificateVerify” step, which is a signature of the entire handshake up to that point made using the private key of the presented certificate, the peer checks this and aborts connection if there is a mismatch

from what I understand this, along with the handshake traffic secrets, protects the certificate exchange from MITM on both sides

https://www.rfc-editor.org/info/rfc9846/#tls-full

@froge Hmm. Could an MITM not simply substitute the whole CertificateVerify signature with one that it generates itself, using its own private key?

@charlotte Right, the case I'm thinking of here is that the MITM is passing data from server->client through as-is, and only interfering from client->server to spoof the pairing process. But now that I describe it, I'm not sure whether that'd actually be possible?

@joepie91 @oilheap is there a reason not to treat the entire handshake process as atomic? Once the handshake has completed, the server has verified the client certificate and the client has verified the server certificate, they won't change after that.

@lambda @oilheap That is broadly how it works (hence pairing) but I'd like to avoid TOFU on the client side if I can.

@joepie91 these fuckers playing god are the reason mixed context websockets are fucked, thanks;

@joepie91 @oilheap why TOFU? Assuming it's because you don't have a CA for the server certificate, I'm not sure how the ordering of certificate checks would have any impact on whether or not you have to TOFU.

@joepie91 a MITM can put in their own cert and then that will be "paired". But the handshake won't complete for the original client, it will be locked out.

@oilheap Would it still be possible for the MITM to pass through messages from server -> client without breaking the client's validation of the (known/pinned) server certificate, leading the real client to believe that the pairing protocol succeeded, while really pairing (ie. presenting) the MITM's own client certificate to the server?

I can probably work with "client gets MITMed and their whole pairing process never succeeds", but "client believes it paired successfully while actually there's an attacker pairing" would be a bigger issue, and I'm a bit fuzzy on exactly how possible one-way MITM is in (modern) TLS.

@lambda @oilheap The client knows and pins the server fingerprint but not vice versa. The server discovers the client fingerprint by looking at the fingerprint of the (successful) pairing/challenge connection. If the client fingerprint can be spoofed during that process, it functionally becomes TOFU (but only for the client FP).

@joepie91 @froge tampering with this will be prevented at the end of the handshake, with client handshake finished and server handshake finished.
https://tls13.xargs.org/#server-handshake-finished/annotated
https://tls13.xargs.org/#client-handshake-finished/annotated

@joepie91 @froge I think that should answer the entire question?

@decemberflower @froge So, let me reason through it to see if I understand this right:

1. Early on, the handshake calc is generated. This requires having the private key of either the client *or* the server, to be able to do.
2. But an MITM trying to do one-way MITM has neither the true client's private key, nor the server's private key, so it cannot generate a shared secret between both.
3. The entire handshake sequence is later validated using this handshake calc. To get a valid result, you need to have calculated the same key as the other side.
4. The client pins the server's fingerprint, therefore it will reject any connection that doesn't present the server's public key/certificate.
5. The client will have calculated with its own private key and the server's public key, therefore (see point 2) the MITM cannot produce a passing validation at the end.
6. Thus, the client will never believe that it is connected to the pinned server if there is an MITM, *even if* the MITM only tampers in the client -> server direction.

Does that sound right?

@joepie91 how does the client get its certificate in order to present it to the server? Because I think that is part of the answer to your question. With a client cert I believe that although the server doesn't know the certificate in advance, it would normally be signed by an authority the server trusts; a MITM device should not be able to obtain a certificate signed by that authority in order to present to the server.

But I'm most definitely not an authority on PKI. Maybe this is one for @soatok !

@http_error_418 @soatok This is an entirely CA-less mechanism (think more P2P and less enterprise infrastructure), so it relies heavily on pinning specific certificates. Already have a couple running conversation threads about it by this point, though :)

@joepie91 If there's no previous established exchange between the two peers there's no mitm.

The way you describe things , the attacker would ask the server to establish the connection with him, then reuse the same TLS context for another peer you want to mitm.

This would not bring anything but create a TLS connection between the attacker and the server with the victim having it's own TLS context unless the server is mishandling those.

A mitm , in classical , would proxy the victim traffic thought himself with its own TLS context that he can spoof since he controls the key exchange and then forward it to the legit server via its own context to it .

Attacking before the fingerprint process is done os like telling two people's who didn't said hello to each others yet, hello will imitating one of them.

@shalien Yes, that is the precise MITM scenario I am modelling here - client knows what the server fingerprint must be, but not vice versa, and I am trying to determine whether a one-way MITM (spoof client FP during pairing) is possible in this scenario.

@joepie91 @oilheap you keep saying "pairing/challenge", is this some higher-level check you're implementing on top of the TLS connection, or are you talking about the normal TLS handshake and key exchange?

If the client pins the server certificate, the client can be sure it's talking to a real server without a MITM. You're still fundamentally missing *some* way for the server to distinguish between a "valid" client and some arbitrary other client though.

@lambda @oilheap Yes; I'm using TLS mutual auth (via OpenSSL) as a mechanism for a custom design, involving no third-party clients or servers.

That last part is the part I'm trying to work out; I have a challenge token and all that for a client to prove its legitimacy, but I want to rule out the possibility of a one-way MITM being possible that lets an attacker have *their* certificate pinned in the pairing process, as a result of the *true* client completing the pairing process.

@joepie91 to me, "mutual authentication" simply means using both server and client certificates. Is there some other definition I'm not aware of that also includes challenge tokens of some sort?

Okay, so you give the client a challenge; what cryptographic secret does the client use to answer that challenge, and how does the server verify that the client used the correct secret? Would it not be possible to simply use the client key as the secret, and do away with the challenge-response?

@lambda No, the challenge token is part of the pairing process. It is simply a single-use token that the client provides to the server upon first (server-authenticated) connection, which the server then treats as proof that the client FP is the right one. This means only one FP+token needs to be passed around out-of-band, instead of two bidirectionally. Usability thing.

But this feels like it's veering off quite a bit from the original question on whether a one-way MITM is possible, and a full design review is honestly not really something that I have time/spoons for right now...

@joepie91 also, if you have some sort of higher-level challenge-response setup, why do you need client certificates at all? Can't you just do the challenge-response at the start of every connection to verify the legitimacy of that connection?

@joepie91 to me, client certificates and a higher-level challenge-response mechanism are either-or; they solve the same problem in two different ways. I can't think of a reason to use *both* at the same time.

@joepie91 okay, I understand now, you want to minimise OOB data transfer (and need to perform it at connection time, not ahead of time during production or whatever).

In that case, since the client will only ever talk to the legitimate server (pinned FP), there is no way for a MITM to obtain the token. Open the TLS connection as normal, but treat the client cert as provisional on the server until the client has provided the token, only then pin and trust the FP of the client certificate.

@lambda Right, that's what the current implementation looks like, basically. Out of curiosity, which mechanism specifically prevents someone from impersonating the client (while passing through the true client's messages as-is)? I think I have an idea now, but I'm not confident of it.

@joepie91 again, once the TLS handshake is complete, the certificates are immutable. The server is definitely talking to a client in possession of the provided certificate, and the client is definitely talking to a server in possession of the provided certificate. The server initially has no idea *who* this new client is, but as soon as the client provides the token over the established connection, the server knows that the client certificate belongs to someone in possession of the token.