0

While reading about Domain Fronting (and Google and Amazon's decision to ban it), I came across this blog where the author has identified domains that allow fronting.

From the blog, doing something like

curl -s -H "Host: images-na.ssl-images-amazon.com" -H "Connection: close" "https://cdn.atlassian.com/images/I/01rgQ3jqo7L.css"

will allow us to access the said CSS file from the images-na.ssl-images-amazon.com domain even though all surveillance systems will show that we connected to cdn.atlassian.com system. I tried to change the Host to something else (say wikipedia) and Cloudfront gave a "Bad Request" error so presumably both the sub-domains have to be on the same domain. (cdn.atlassian.com is hosted on cloudfront from their dig records).

My Questions are:

  1. If Amazon has already banned fronting why is it possible to successfully make the above request?
  2. At a practical level, how can a malicious user leverage fronting for hosting a malware C&C service?
  3. Are there any best practices using which an individual customer ensure his subdomain (say xyzabc.cloudfront.com) is not susceptible to fronting?

EDIT

Additional question:

  1. Is domain fronting something that only CDNs have to worry about or can a poorly configured stand-alone web-server also be (ab)used as a front?
Improve this question
2

2 Answers 2

Reset to default
1

If Amazon has already banned fronting why is it possible to successfully make the above request?

Amazon hasn't banned domain fronting yet.

At a practical level, how can a malicious user leverage fronting for hosting a malware C&C service?

Without domain-fronting, proxies can see the target host via SNI, and can choose to block the request to protect the user.

Domain-fronting works since it's faking the host in SNI. If the fake host is important enough, like google.com, the traffic won't be blocked.

Can an individual customer ensure his subdomain (say xyzabc.cloudfront.com) is not susceptible to fronting?

Create another subdomain on the same host, and use cURL to check:

curl -s -H "Host: subdomain2.host.com" -H "Connection: close" "https://subdomain1.host.com/"
Improve this answer
5
  • If the fake host is important enough, like google.com, the traffic won't be blocked. Does that mean the client completes handshake with google.com and as part of application data sends HTTP request for host my-domian.com? Wouldn't google just show a 404 or refuse to serve a request for different host?
    – RedBaron
    May 4, 2018 at 10:23
  • 1
    Also for point 3, I meant if there are any configurations (for Apache, Nginx) that can ensure I am not susceptible to domain fronting?
    – RedBaron
    May 4, 2018 at 10:24
  • 1
    @RedBaron: the load balancer completes the hand shake based on SNI, then redirect to the correct application server based on Host header. As long as the load balancer has a certificate for the SNI host, then the connection is accepted, and since the traffic is redirected to the correct server, then google.com can't send a 404 since it doesn't receive any traffic.
    – Benoit Esnard
    May 4, 2018 at 11:06
  • 1
    Ah that makes sense. So fronting is possible primarily because of load balancer (or more generally a short SSL termination). But the google's load balancer should possibly refuse to service a request for a completely different host (say amazon.com)?
    – RedBaron
    May 4, 2018 at 11:33
  • It can refuse the connection if it sees that the SNI host doesn't match the HTTP host, and that's what they plan to!
    – Benoit Esnard
    May 4, 2018 at 11:45
0

You can use openssl to see a working example of domain fronting. This example will illustrate creating a TLS connection to a Google server, secured with a certificate issued to *.google.com. Then we will request a resource from a different domain (www.youtube.com) through the connection secured by the *.google.com certificate.

Start with the following openssl command. Note the google.com is specified in the -connect parameter. This means that openssl does a DNS lookup to get the IP address that google.com points to, and openssl then connects to the server at that IP address. Also note that google.com is specified in the -servername parameter. This means that openssl sends google.com in the SNI request, to tell the server to use the certificate for google.com to secure the connection (in case there are multiple domains hosted at this IP address).

openssl s_client -showcerts -crlf -servername google.com -connect google.com:443

A TLS connection is established. Looking at the certificates, we can see that the the SAN in the leaf certificate is indeed *.google.com. To someone observing the connection, this would appear as an ordinary TLS connection to google.com.

Next, type the following HTTP request (followed by two linefeeds after the second line):

GET / HTTP/1.1
HOST: www.youtube.com

This is a GET request for the resource at /, from the host www.youtube.com (not www.google.com!). Note that the request is sent through the secure connection to the server, secured using the certificate for *.google.com.

As you can see, server responds with the homepage for www.youtube.com, through the connection to the server secured with the certificate for *.google.com.

Improve this answer
2
  • Basically its like instead of issuing your own SSL certificates to setup HTTPS on your website, you "mislead" the connection to use somebody else HTTPS certificates, although routing the traffic to you :) Of course this can be used for bad, since you can use a reputable HTTPS from somebody else, but its going to another destination.
    – Miguel
    Nov 9 at 17:27
  • @Miguel, That's one way to look at it. But, it won't work with a normal browser, because a normal browser would never send one FQDN for the SNI, and a different FQDN for the host in the GET request.
    – mti2935
    Nov 9 at 17:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .