Domain fronting is a technique to circumvent the censorship employed for certain domains(censorship may be for domains not in line with company’s policies or may be because of the bad reputation of domains).Domain fronting works at HTTPS layer and uses different domain names at different layers of the request(more on this later).To the censors, it looks like the communication is happening between the client and an allowed domain whereas, in reality, the communication might be happening between the client and a blocked domain. Domain Fronting works at HTTPS layer and under these different requests for hostname will be different at different layers. In Domain Fronting, hostname information will be same for DNS request and SNI whereas HTTP host header which is hidden from censors from HTTPS encryption will carry another hostname. The outside addresses will typically be those of a CDN that would have a large number of domains behind it (such as s3.amazonaws.com), and the host address would be a small “reflector” hosted on that CDN. The reflector would be a small application that forwards traffic in the HTTP request to wherever it needs to go and forwards the responses to the client through the HTTPS tunnel. Thus the initial DNS request and Client Hello are sent in the clear and are visible in packets, but the inner HTTP traffic is sent through the encrypted tunnel. SNI stands for Server name Indication and is an extension of TLS protocol which allows a server to host multiple hostnames under the same IP. With this extension, clients can specify the domain they want to connect with in the initial TLS request which allows the server to select the appropriate certificate to negotiate with the client. For example, if we query google.co.in using OpenSSL clients, we see that the returning certificate is not for the issued request.
Looking at the x509 certificate reveals more information about the frontal server and other sites under the same frontal.
As you can see in the above screenshot that, same frontal also accepts connections for *.appspot.com which is the domain issued for apps hosted on Google App Engine. As you might have guessed that if *.appspot.com is blocked by censorship and if the frontal is not, then the request will succeed, and to the monitoring team, only a request for frontal will be seen. To see the actual destination, TLS should be broken to see what is inside HTTP header.
Tor is configured on the client with meek plugin. The client sends an HTTP request to the Tor bridge via a CDN. Client protects the bridge domain name from the censor by fronting it with an allowed name. Front end server (from CDN) decrypts the request and sends the request to the destination mentioned in the HOST header. Bridge sends the data back to the client in the HTTP response
Domain Fronting and meek works when CDN blocks some of the domains but not all of them. Default bridge lines can be found here, and the CDN can be changed by altering the front parameter while installing meek. Below are the some of the services that can be used with TOR:
Meek-amazon Meek-azure
So in this article, we have looked into a very clever technique to bypass censorship which is gaining popularity among APT authors as well.
