http is used instead of https

[lostact]

In the wget command that is used to check if domain fronting works or not you are using http://" + subDomain + "." + domain + "/df.txt.

I don't know it it is a typo or something but the whole point of domain fronting is to use a popular domain as SNI and pass another domain in Host header, but http has no SNI, so the only difference this command has with wget domainfronter.pages.dev\df.txt is that instead of our domain it uses a subdomain from the list for the dns query, which is practically the same as our domain anyway, both point to cloudflare ips.

I also read your paper and was suprised to see this mistake, even for confirming your results in cli you used http. If you use https you will get "421 Misdirected Request" error from cloudflare which is because SNI and Host header are not the same.

I changed http to https in the code and tested a few domains and not a single subdomain was frontable, confirming that cloudflare, as they have said before is blocking domain fronting.

[cmiller-umbc]

hey lostact!

firstly, thank you so much for taking the time to read through my research and provide additional insight. I really haven't had all that much input throughout this process so it means a lot!

so domain fronting is originally defined using wget to prove the concept, which initially confused me during my research because I'd assumed wget was forcing TLS (like how curl does) and didn't realize it was HTTP until I intercepted the packets from my lab and was able to read the host headers. We were aware of this while writing the paper/presentation and explicitly refrain from saying that the tool provides domain fronting as a service (even though maybe you could argue that it does based on the original definition, but like you said, that ultimately would have felt misleading). The paper discusses how domain fronting works, and then presents a tool for identifying the servers of a cloud infrastructure that could be used for domain fronting because they were willingly passing packets with fronted packet headers. As much as I wanted to have a fully developed privacy tool that would basically VPN your traffic through Azure, it was not feasible in the time frame I had. Hopefully that helps clarify the limitations of domainfuzzer.py as it is purely a reconnaissance tool, and not a privacy tool.

When you were testing through cloudflare, what were you using to try and alter your packet headers? Admittedly, I haven't done much testing through cloudflare beyond what is in the paper as I decided to focus more on azure. I found this article from DigiNinja very helpful when troubleshooting packet manipulation through cloudflare and he/she successfully domain fronts encrypted traffic (HTTPS) through cloudflare after being told by cloudflare it was impossible: https://digi.ninja/blog/cloudflare_example.php

I've tried a few different methodologies for forcing TLS on fronted packets through Azure (curl and scapy) and was surprised at the wide variation in results. A few of the domains would return a "200 OK" but not the payload, and the other domains would return 300s, 400s, and a few 500s. I was not able to find any uniformity in how Microsoft's edge servers responded to the exact same GET requests, which to me says that there is no standardization in their configuration (or security) and this is probably a good place to keep digging. Unfortunately, I have yet to successfully receive the encrypted payload sent, however another researcher named Adam Stuart, was able to using curl back in November: https://www.youtube.com/watch?v=4xetfIPCG84

I've had to put this project aside since about July of last year but if this is something you are researching personally and have any additional input or ideas, I would be more than happy to hear them! TLSv1.3 is going to become the global standard at some point and there's been a lot of discussion around the use of the Encrypted Hello packet header (https://blog.cloudflare.com/announcing-encrypted-client-hello), which we should be able to leverage to domain front packets as only the recipient can decrypt the eSNI or ECH headers. Looks like Azure is rolling out TLSv1.3 as we speak: https://techcommunity.microsoft.com/t5/azure-integration-services-blog/announcing-the-availability-of-tls-1-3-in-azure-api-management/ba-p/4047586. I'm reasonably positive that there's a way to force azure edge servers to proxy fronted traffic with TLSv1.2, but as far as I understand, they have a solution in place for preventing us from using the encrypted headers available in 1.3 and as soon as it is the default protocol for HTTPS, I'm very hopeful we see a resurgence of domain fronting. Read through those articles and let me know what you think!

[lostact]

Thanks for your response, Im working on censorship resistance systems and as it is discussed in a recent paper, On Precisely Detecting Censorship Circumvention in Real-World Networks, host-based echniques used by censors constitute a significant threat to censorship circumvention tools. A good way to defend against host-based echniques is to use domain fronting, to hide both destination domain and IP of the proxy. Other than that in some areas censors may impose SNI whiletisting which is a high collateral but effective approach to disable circumvention tools.

Tools like meek have been developed in the past to use domain fronting but unfortunately in the past years most CDNs disabled domain fronting either completly or partially, making these tools very hard to use.

Some CDNs (like GCore and Fastly) still allow domain fronting and some others (like AWS) allow domain fronting on domains registered on the same account but cloudflare does not allow any kind of domain fronting, in general it seems cloudflare has the hardest stance against domain fronting among other CDNs. I also tried host header manipulation and it didn't work on cloudflare.

Since cloudflare has the majority of market share by a large margin, censors can easliy block other CDNs if used widely for domain fronting, and allow only cloudflare. Also most proxies take advantage of Websockets which only a few CDNs offer (including cloudflare).

So my focus was mainly on cloudflare and I didn't found any method to bypass their limitations, I guess I have to look elsewhere. ECH may be a good option but until it is adopted by the majority of the internet users, censors can block it too with ease.