Is HTTPS really S?

The Attack

A popular way of obtaining a certificate is by proving to some certificate authority (CA) that you are in control of a given domain. One way to prove it is by serving an arbitrary file (given to you by the CA) under the IP that your domain resolves to. To validate that, the CA performs an unencrypted HTTP request to your IP. It cannot be encrypted because you are in the process of setting up a certificate, so you are only serving plain HTTP content. And unencrypted HTTP communication has this unwanted property that it can be intercepted and modified by anyone who happens to be between your server and the CA. At first glance, there may seem to be no risk, as you only need to prove that the contents of the given file can be accessed.

However, the attacker can start their own process of obtaining a certificate for your domain. In this scenario, the CA would send a request to your IP. If the attacker can intercept this request and send a valid response to the CA instead of forwarding it to you, then they can obtain a valid certificate for your domain. In order to be able to capture that transmission, they need to be in between your server and the CA - they could be your internet service provider, or any of the backbone operators of any of the countries through which that request is routed. By selecting from different available CAs and analysing the routes between them and your server, the attacker has multiple options to craft a route. If they are a large internet operator in any country, there is a large chance that they could select such a CA, that their infrastructure is in between your server and that CA.

To minimise this risk, the official documentation of this protocol [1] recommends that CAs should perform more than one query to the target IP, starting from different places in the network. That would indeed make the attack much harder if the attacker is far from the victim server. The closer they are though, the easier it gets to workaround this defence. In particular, if the attacker is your internet service provider, or the backbone internet service provider, then there's a high chance that they will serve all the traffic to your server anyway, which means that they can intercept it.

There are other similar attacks, such as certificate spoofing, CA spoofing, and using compromised CA's certificates, however, all of these have some significant limitations. For example, using a compromised CA's certificate requires you to first compromise a CA, which is certainly not an easy task. Spoofing by using self-signed certificates or fake CAs is easy to detect; any browser would display a significant security warning before allowing you to proceed to that page. Lastly, being a dishonest CA and issuing valid certificates for themselves to act as an attacker is very risky because it leaves a trace - the certificate itself would reveal the primary suspect. The attack described above has none of such limitations.

Once the attacker has a valid certificate, they also need to capture your traffic when you want to open your website. While this may be challenging in practice (unless they are your internet service provider), the plain TCP/IP infrastructure is not always completely secure, and there are known attack scenarios on how to redirect your traffic via attackers nodes. In the end, that is one of the very reasons why we want to use the certificates.

Looking at Mitigations

We used a self-hosted service as an example, but this attack could occur in various scenarios. There are a few steps that can be taken to mitigate the risk. First, and most important, is certificate transparency. All major CAs log all the certificates they issue and make them accessible for monitoring. You can actively monitor if any certificate was issued for your domain without your initiation and in such a case, contact the CA to revoke the certificate. There are two problems with this approach. First is that not all CAs implement the certificate transparency (most modern browsers only trust those CAs who do use this mechanism, but maybe not all of your clients are using such a browser). The second issue is that certificate revocation is time-consuming. The attacker may perform such an attack before the certificate is revoked. Another mitigation is to use a trusted network (or one that is difficult to control), such as using VPN tunnels - you can do this when you visit your self-hosted cloud, but you can't expect all of your clients to do the same. You can also use certificate pinning to prevent your browser from accepting any certificate other than the one you created. However, similar to the previous mitigation, this method works if you can control your own client environment, but you can't expect all of your clients to do so (yet another limitation of certificate pinning is that it only works for returning visitors and is helpless for first-time website visitors).

Possible Solutions

This appears to be a significant security issue for HTTPS. Some proposed changes that could help mitigate the problem:

1. Order all CAs to stop using file hosting as a way to proof domain ownership. Very simple solution, but potentially disruptive for many end-users who are already using it.

2. All new certificates should have a future start date to enable domain owners to respond if they detect anything suspicious in the certificate transparency logs and revoke the malicious certificate before it becomes valid. Non-disruptive for end-users, but still requires every domain owner to constantly monitor certificate transparency logs, which is burdensome.

3. Consider alternatives to using public key infrastructure and certificates for HTTPS, such as storing the domain public key in the DNS records, similar to how it is done for emails. DNS used to be viewed as potentially untrustworthy and susceptible to spoofing, but with the introduction of Secure DNS (e.g. DNS over TLS), DNSSEC and generally available public DNS providers, these concerns appear to be less significant today. Note that Secure DNS would likely still require to rely on public key infrastructure, but it would be a lot easier to control those, because DNS providers are all professional entities, which could be expected to use additional verification while creating the certificates.

Conclusion

Some argue that if you are a large internet provider or a state, you can likely eavesdrop on any communication anyway, so it is pointless to focus on issues like this. We disagree. Maybe there are plenty of different security holes that can be abused if you are powerful enough, but that does not mean we should give up trying to stay as secure as possible. Therefore, if you require a trusted connection, you should be able to rely on 'extended validation' certificates, which are issued with additional security measures such as validating the domain's owner real identity. Alternatively, exchange public keys via a trusted channel first, instead of relying on public key infrastructure.

Closing Note

We discovered this attack while setting up our self-hosted private server and wondering about its security, but before publishing this article we made sure that IETF is aware of this attack and has nothing against us publishing its details. As far as we know, there is no known roadmap for solving it at the moment.

References