3

TLS client implementations will tend to try and do hostname verification by default for remote TLS endpoints (servers). The client connects to the server, and as part of the negotiation the certificate chain is checked (valid, signed by a trusted CA etc.) and the hostname is also verified (is the hostname that I'm connecting to listed in the server leaf cert SAN list).

As I understand it, the purpose of the hostname verification is to make sure that the certificate being presented by the server was issued for that specific server, so as to prevent a valid and trusted certificate issued for evil.site.com being used for connections to an endpoint reachable as, say, gmail.com. If an attacker controls where a target's packets go (including DNS), hostname verification is something that can prevent traffic being MITM.

However, in the case of a self-signed cert, the dynamic is slightly different. Mainly, the cert won't be trusted by the client by default - it is almost certainly not in the client's root CA list. As a result, a client wishing to make a valid TLS connection to an endpoint protected by a self-signed cert would need to explicitly configure themselves to add the cert into the CA list (or even configure it as the only CA for this connection). By doing this though, the client is effectively ultimately trusting this certificate. Any remote endpoint that presents the same certificate must surely also be trusted, no matter what name was used to access it.

If the server presents a leaf certificate that is the same as the one configured by the client to be a trusted CA for the connection, is there any value in doing hostname verification? If so, what threat is being defended against?

growse
  • 531
  • 3
  • 5

1 Answers1

3

A check of the subject is done if the CA has issued many certificates for different servers and thus just checking the CA (i.e. trust chain) is not sufficient to specify the expected leaf certificate.

But if the expected certificate can be specified with sufficient precision by other means the validation of the subject is not needed. This is for example the case when checking the certificate or its public key against known good values (as done in certificate pinning or public key pinning). This would also be the case if the CA is known to have definitely only issued certificates for this specific site. This is also essentially what browsers do when the user explicitly adds an certificate exception for a site: they remember this certificate as trusted for the specific site (but not for others), no matter if the subject matters or not.

Trusting a specific self-signed certificate by importing it in the trust store is basically pinning to this specific certificate. No further checks of the subject would be needed in this case. Note though that the browser does not know that this self-signed certificate can not be used to sign other certificates if it is imported as a trusted CA - it must assume that it is a generic CA which can issue other certificates and thus subject need to be checked.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I'm still not sure I fully understand why it's relevent that the cert has signed just itself or another cert. If a server presents a self-signed cert which the client is also configured to use as the CA root, what difference does it make that this certificate has also signed a completely separate cert somewhere else? – growse Jan 05 '21 at 10:17
  • @growse: Because the *"separate cert somewhere else"* might be owned by an attacker. If the certificate is imported as a trusted certificate __authority__ (CA) this attackers certificate would be trusted too - unless additional checks are done like checking the subject. – Steffen Ullrich Jan 05 '21 at 11:33
  • Ah I see! I agree that the verification can't be skipped just because the server leaf has been signed by the imported trusted CA. It's only the case if the leaf is identical to the imported CA cert that skipping seems reasonable. But as you say, this is effectively pinning that cert. – growse Jan 05 '21 at 13:32