tialaramex/gist:7c78e677fd58ebde4dea9296ddea17d2

## gistfile1.txt
I've seen more than one "security researcher" arguing basically along the following lines:

1. Prior to TLS 1.3 the Certificate message was plaintext. (True)
2. So a middlebox could see this message without participating (Fine so far)
3. The middlebox could use the contents of this message to reason about the connection (Hmm?)
4. But in TLS 1.3 only SNI is visible not Certificate, and we can't trust that (Oh dear)

Here's the problem: Certificate is largely useless on its own

Certificate is just one or more concatenated X.509 certificates. Those are public documents.

A server can easily send Certificate with say, the www.google.com certificates inside the message, and then allow clients to do RSA key exchange using a separate public key, either hidden elsewhere or baked into the client software rather than the one in the certificate for which the server may not know the corresponding private key. A middlebox can't passively detect this, everything looks fine.

If your threat model assumes your clients are all straight with you, then you only needed SNI anyway, that's sent by the client and you trust it. If your threat model assumes your clients may not be working for you then you also can't trust them to tip you off if the remote server provides a Certificate that doesn't match its true identity.

To be useful a middlebox would need not just Certificate but CertificateVerify but that message didn't even exist (it was client-only before), it's new in TLS 1.3. So this is mourning of a capability that never really existed.

For example, Palo Alto Networks PAN OS 9.0 has a feature named "SSL Decryption Exclusion" which examines the Certificate seen, and on the basis of the certificate seen, may classify the server as technically unsuitable for decryption, whereupon traffic simply passes unmolested.
	I've seen more than one "security researcher" arguing basically along the following lines:

	1. Prior to TLS 1.3 the Certificate message was plaintext. (True)
	2. So a middlebox could see this message without participating (Fine so far)
	3. The middlebox could use the contents of this message to reason about the connection (Hmm?)
	4. But in TLS 1.3 only SNI is visible not Certificate, and we can't trust that (Oh dear)

	Here's the problem: Certificate is largely useless on its own

	Certificate is just one or more concatenated X.509 certificates. Those are public documents.

	A server can easily send Certificate with say, the www.google.com certificates inside the message, and then allow clients to do RSA key exchange using a separate public key, either hidden elsewhere or baked into the client software rather than the one in the certificate for which the server may not know the corresponding private key. A middlebox can't passively detect this, everything looks fine.

	If your threat model assumes your clients are all straight with you, then you only needed SNI anyway, that's sent by the client and you trust it. If your threat model assumes your clients may not be working for you then you also can't trust them to tip you off if the remote server provides a Certificate that doesn't match its true identity.

	To be useful a middlebox would need not just Certificate but CertificateVerify but that message didn't even exist (it was client-only before), it's new in TLS 1.3. So this is mourning of a capability that never really existed.

	For example, Palo Alto Networks PAN OS 9.0 has a feature named "SSL Decryption Exclusion" which examines the Certificate seen, and on the basis of the certificate seen, may classify the server as technically unsuitable for decryption, whereupon traffic simply passes unmolested.