How do websites prevent certificate forgery?

Question

I have recently developed interest about Wireless hacking, and I have seen in many instances in videos and stuff that people are (or more correctly, were) able to perform some kind of MitM attack using evil twin method against big websites like FB, GMail.

There are plenty of tools that automate fake AP creation and include additionally tools like SSLStrip and SSLSplit in order to try to bypass TLS/SSL and HSTS.

As long as I know HSTS to work, the client must have visited the same website at least once. But, this is not a big deal now, cause there is HSTS Preloading from browsers, and all the famous websites are already included there, so even if the client is entered to the website for the first time it still will run HSTS. On the other hand, I believe these websites also use certificate pinning (a concept that I'm not very familiar), which as long as I know means that instead of using the certificate trust chain, they directly specify for which certificate to look, and if the certificate is different just terminate the connection.

On the other hand, I believe the tools that try to bypass these technologies, use the idea that people don't type www.facebook.com, but instead type just facebook.com, so that the tools can redirect the request to let's say wwww.facebook.com, for which it is possible to forge a certificate. But, I believe this is no longer true. But what's preventing the attack from being able to forge the certificate for some nonsense subdomain of the official website, the certificate pinning or HSTS, or both? Also how does HSTS and certificate pinning work together?

Answer 1

The behaviour of HSTS is variable depending on whether the includeSubdomains directive is applied. In the case of HSTS without includeSubDomains, a user visiting www.facebook.com wouldn't protect them if they accidentally went to ww.facebook.com without an explicit HTTPS prefix. However, when the includeSubDomains directive is applied, visiting any subdomain (or the root domain) causes the HSTS rule to be applied across all subdomains. This can also be applied as part of preloading.

Pinning is a separate measure and can be achieved in a number of ways. The main two are preloaded pins in the browser (e.g. Chrome's pinning) and HTTP Public Key Pinning (HPKP). Another less-common way for pinning to be achieved is with a tool such as Microsoft EMET which adds additional pinning rules to the system. The goal of pinning is to store some identifier for the certificate (or its associated signing certificate) so that a false certificate from a compromised (or otherwise lax) certificate authority cannot be used to compromise communications.

In the case of preloaded pinning rules, the public key of the CA's root signing certificate or intermediate signing certificate is stored in the browser and the chain is verified when a certificate is presented for a matching domain. It is extremely rare to see leaf certificates (i.e. the actual specific certificate for the domain, rather than an intermediate or root certificate) in pinning rules due to the difficulty in maintaining this list when dynamic load balancing is in place.

In the case of HPKP, this feature works in a quite similar manner to that of HSTS. When a user visits the site, a header is returned which contains a list of hashes of public keys for valid certificates (either signing certs or the certs themselves). When the user revisits the site at a later date, the browser has cached this HPKP rule and can use it to verify that the newly presented certificate is still valid, and hasn't been spoofed either by self-signing or via a different (potentially compromised) CA. This feature also has the includeSubdomains directive, which can be applied to the HPKP header to state that all subdomains should be considered part of that rule. One additional feature of HPKP over in-browser pinning is that a "backup" signing key must be included as part of the HPKP rule, so that it can be used to update the HPKP rule if the original certificates expire.

With both of these features in place and the includeSubdomains directive applied to both, the following attack methods are mitigated:

• Attackers who spoof DNS records to point to their IP cannot provide a self-signed certificate or any certificate with errors; browsers will not allow a click-through when the HSTS rule is in place, and the HPKP rule forces the certificate to match the given signing rules.
• An attacker who compromises a CA, or who operates their own generally-trusted CA (e.g. nation states) cannot supplant the original certificate with their own, as HPKP forces a list of trusted CAs to be used.
• Users who attempt to directly visit http:// are redirected by their client to https:// automatically; the browser will not communicate over plain HTTP with the server.
• Attackers who spoof DNS records to a fake canonical name within the same root domain cannot spoof the certificate for this alternative subdomain; the includeSubdomains directive on each header causes all subdomains to be protected.