Domain Fronting in Signal Article

Domain Fronting in Signal

What is domain fronting?
- History
  - Cozy Bear in 2017
  - Signal in 2018
    - Blocked by google later on
  - Reimplemented by google
How do applications use it?
- Signal
- TOR
Timeline of domain fronting in Signal
Going forward

Draft 1

Adopted by the encrypted messaging platform Signal since 2016, domain fronting has been a tool used for evasion of censorship and malware delivery. Domain fronting is a technique utilizing a well-documented loophole within TLS (see RFC) in order to masque traffic from one origin behind another, typically utilizing the infrastructure of Google Cloud Platform or Amazon Web Services. Notably, Signal uses domain fronting to evade censorship within Oman, the United Arab Emirates, Qatar, and Egypt. First declared dead in April of 2018 by Google and Amazon, domain fronting has been quietly been used within Signal on Google Cloud Platform since April of 2019. This paper discusses the origins, the current progress, and the current Signal implementation.

History

Domain fronting via The Onion Router (TOR) network gained widespread awareness in 2017 when it was used by the Russian hacker group Cozy Bear (also known as APT29) in 2017. Investigated by FireEye, Cozy Bear utikized domain fronting to distribute malware from what appeared to be appspot.com, a domain name used by Google as part of their cloud platform (https://www.fireeye.com/blog/threat-research/2017/03/apt29_domain_frontin.html). Signal, a commonly used encrypted messaging app, has utilized domain fronting in the past in order to maintain connectivity behind countries that censor traffic, beginning in 2016 (https://signal.org/blog/doodles-stickers-censorship/). In March of 2018, Google moved to shut down the most commonly used endpoints for domain fronting within their cloud service splatform, forcing Signal to switch over to using Amazon Web Services, a similar cloud platform operated by Amazon (https://github.com/signalapp/Signal-Android/commit/a573ab7c7668360c3ab411627bbb23109ef9facc). However, in May of 2018, Amazon moved to also shut down domain fronting within their platform (https://signal.org/blog/looking-back-on-the-front/), forcing Signal to find an alternative.

Technical Background

Domain fronting requires knowledge of several pieces of internet infrastrure.

HTTP and HTTPS

HTTP (Hyper Text Transfer Protocol) and HTTPS (Hyper Text Transfer Protocol Secure) are web protocols used to request documents via the internet. HTTP is a plaintext protocol, involving a message body and various headers, containing information for user side applications to consume. Specifically a “Host” header denotes where the HTTP message came from, similar to a return address on an envelope.

However, as a plaintext protocol, any information sent via HTTP is readable to anyone, including censors, routers, even other users sharing the same Wifi network. HTTPS was specifically created to secure these messages, utilizing Transport Layer Security as a cryptographic protocol to encrypt messages.

TLS and SNI

Transport Layer Security (TLS), alongside with its predecessor secure socket layer (SSL), were originally introduced in 1999, but did not see mass adoption until the late 2000’s. However, TLS by itself only mandates that a user and a host negotiate via a certificate exchange: a client requests a certificate from the server, and the client compares the certificate versus the expected result before proceeding with the document transfer. If the certificate does not match, the user is alerted and given a choice on how to proceed with the connection. This cryptographic process, also called the TLS handshake, allows the user and the server to agree on a cryptographic key to ensure that no one else can decrypt the messages passed between the user and the server.

However, TLS is used to establish a secure connection before any data is transferred via HTTP, since the correct cryptographic keys must be negotiated before the server starts to communicate data. This means that the data present in the “Host” header must be sent alongside the TLS handshake, even before any HTTP messages are sent. As a result, Server Name Indication (SNI) was added as an extension to TLS (https://tools.ietf.org/html/rfc6066#section-3) in 2003.

Cloud Platforms

Cloud platforms such as Amazon Web Services, Google Cloud Platform, Microsoft Azure, and Alibaba Cloud, along with smaller players, allow programmers to run their code on servers owned by Amazon, Google, Microsoft, or Alibaba, respectively. While each cloud platform has multiple options for programmers to run their code, this paper will focus on three product offerings used for domain fronting in the past: Google App Engine, Google Cloud Functions, and Amazon Souq. Google App Engine is a simple, lightweight way for programmers to write code meant to be executed for the web. All applications deployed on Google App Engine use the same base domain when running code: appspot.com. For example, a developer creating an application called “test-app” would have the domain test-app.appspot.com.

Google Cloud Functions is a similar product offering to Google App Engine, with many similarities, including allowing developers to run custom code behind the same domain: cloudfunctions.net.

Amazon Souq is a subsidary of Amazon acquired in 2017. The website offers much of the same products as Amazon, and now has mostly been rebranded with the main Amazon brand, but retained a distinct domain called cms.souqcdn.com. This domain was used for a content distribution network (CDN), which mirrored static website assets such as images to be physically closer to users, enabling faster data transfer rates.

Implementation of Domain Fronting and the Use Case of Signal

Common censorship mechanisms employed by Iran, the United Arab Emirates, Turkey, and others is SNI filtering and domain name server (DNS) filtering. While the specific implementations of these censorship models are beyond the scope of this paper, both involve inspecting packets as they flow from the user to servers, checking for specific information, typically the “Host” denoted in the SNI tag, as well as any information for plaintext HTTP. This is a “cheap” censorship: filtering in this manner is computationally cheap, meaning users will typically not see a huge decrease in internet speeds, and monetarily cheap, as it is easy to implement with off the shelf solutions. For example, Turkey employed both SNI filter and DNS filter in late Feburary 2020, blocking Facebook, Twitter, and Instagram (https://netblocks.org/reports/social-media-blocked-in-turkey-as-idlib-military-crisis-escalates-r8VWGXA5) during the incursion into Idlib.

Domain fronting can bypass SNI filtering and DNS filtering, because HTTPS requests wrap the plaintext HTTP information with TLS. similar to a letter with one return address on the outside, but containing another envolope with a different return address on inside. In this analogy, the return address on the outside might be google.com, while the return address on the envelope contained would say signal.org. Here, this “return address” is the Host header within a HTTP request. Because the censor cannot open the envolope due to the cryptographic guarentees provided by TLS, it must decide whether to censor the outer envelope entirely, thereby blocking google.com, or allow the letter to pass through.

Further extended, domain fronting can be used by any actor from any Cloud Platform, as long as the CDN or the cloud platform is not completely blocked. Because of this, domain fronting through Google Cloud Platform is not available in the People’s Republic of China, due the complete block on google.com.

Signal first outlined their usage of domain fronting in December of 2016 (https://signal.org/blog/doodles-stickers-censorship/), utilizing domain fronting from Google App Engine, or appspot.com. This presented most censors with the choice to either block a large portion of Google traffic and potentially rendering Google Services unusable. However, Google later announced that it was shutting down domain fronting (https://github.com/signalapp/Signal-Android/pull/7584).

As a result, Signal switched over to using Amazon Souq for domain fronting in March 2018. Later that year, Amazon also decided to announce they were shutting down domain fronting in May of 2018, but quietly allowed it until April 2019 (https://github.com/signalapp/Signal-Android/issues/8736). This was fixed within later versions of Signal, although Open Whispher Systems has chosen to be mute on the details.

In digging into the Signal Android and Signal iOS code, we can see that the problem was resolved as of commit https://github.com/signalapp/Signal-Android/commit/9aed2343c141b1b3809f7eaccce61c22e342fda7, with an amusing commit message of “Attempt to resolve connectivity problems for some users”. Notably, the SignalServiceUrl has been appened with specific sections for Egypt, UAE, Oman, and Qatar. In changing from the cms.souqcdn.com to google.com, it is clear that Signal is now using domain fronting via google.com.

However, as noted above, Google shut down the capacbility to use domain fronting in 2018. It becomes clear upon further digging that the SERVICE_REFLECTOR_HOST constant has changed from europe-west1-signal-cdn-reflector.cloudfunctions.net from textsecure-service-reflected.whispersystems.org. In digging into the iOS version of the Singal application, this constant is defined as censorshipReflectorHost, which is then called within https://github.com/signalapp/Signal-iOS/blob/13a69e3af350f77e3abb4f6c85b9229e4dc4cf3d/SignalServiceKit/src/Network/OWSSignalService.m#L243, a portion of code that specifically calls for the HTTP “Host” header.

As mentioned above, cloudfunctions.net is a service provided by Google Cloud Platform. Due to Signal’s parsing of the host header from this domain, we can assume that, despite not seeing the code that powers europe-west1-signal-cdn-reflector.cloudfunctions.net, domain fronting is still being used.

What now?

While cloudfunctions.net is a Google domain and presents most of the same challenges for censors as blocking google.com, it is concievable that censors could filter cloudfunctions.net by restricting access to certain functionality within Google Cloud Platform. Cloud functions are one of the many products offered by Google Cloud Platform, and, as in the case of China and Amazon Web Services, Amazon does have a special version of Amazon Web Services made for the Chinese market (https://www.amazonaws.cn/en/), which includes different functionality and products. This means that, at some point, these Middle East countries could ask Google to comply by restricting the product offerings.

However, domain fronting remains an effective way of circumventing censorship by effectively camoflaoughing network traffic. Even if this particular domain fronting endpoint is shut down, it would be a matter of time before another domain was found, as in the case of Signal moving from Google Cloud Platform to Amazon Web Services, and back to Google Cloud Platform once again. It is conviacble that further attempts to crack down on domain fronting would see Signal move to Microsoft Azure, or even Alibaba Cloud.

Draft 2

Adopted by the encrypted messaging platform Signal since 2016, domain fronting has been a tool used for evasion of censorship and malware delivery. Domain fronting is a technique utilizing a well-documented loophole within TLS (see RFC) in order to mask traffic from one origin behind another, typically utilizing the infrastructure of Google Cloud Platform or Amazon Web Services. Notably, Signal uses domain fronting to evade censorship within Oman, the United Arab Emirates, Qatar, and Egypt. First declared dead in April of 2018 by Google and Amazon, domain fronting has been quietly been used within Signal on Google Cloud Platform since April of 2019. This paper discusses the origins, the current progress, and the current Signal implementation.

History

Domain fronting via The Onion Router (TOR) network gained widespread awareness in 2017 when it was used by the Russian hacker group Cozy Bear (also known as APT29) in 2017. Investigated by FireEye, Cozy Bear utilized domain fronting to distribute malware from what appeared to be appspot.com, a domain name used by Google as part of their cloud platform (https://www.fireeye.com/blog/threat-research/2017/03/apt29_domain_frontin.html). Signal, a commonly used encrypted messaging app, has utilized domain fronting in the past in order to maintain connectivity behind countries that censor traffic, beginning in 2016 (https://signal.org/blog/doodles-stickers-censorship/). In March of 2018, Google moved to shut down the most commonly used endpoints for domain fronting within their cloud service platform, forcing Signal to switch over to using Amazon Web Services, a similar cloud platform operated by Amazon (https://github.com/signalapp/Signal-Android/commit/a573ab7c7668360c3ab411627bbb23109ef9facc). However, in May of 2018, Amazon moved to also shut down domain fronting within their platform (https://signal.org/blog/looking-back-on-the-front/), forcing Signal to find an alternative.

Technical Background

Domain fronting requires knowledge of several pieces of internet infrastructure.

HTTP and HTTPS

TLS and SNI

Transport Layer Security (TLS), alongside its predecessor secure socket layer (SSL), were originally introduced in 1999, but did not see mass adoption until the late 2000’s. However, TLS by itself only mandates that a user and a host negotiate via a certificate exchange: a client requests a certificate from the server, and the client compares the certificate versus the expected result before proceeding with the document transfer. If the certificate does not match, the user is alerted and given a choice on how to proceed with the connection. This cryptographic process, also called the TLS handshake, allows the user and the server to agree on a cryptographic key to ensure that no one else can decrypt the messages passed between the user and the server.

However, TLS is used to establish a secure connection before any data is transferred via HTTP, since the correct cryptographic keys must be negotiated before the server starts to communicate data. This means that the data present in the “Host” header must be sent alongside the TLS handshake, even before any HTTP messages are sent. As a result, Server Name Indication (SNI) was added as an extension to TLS (https://tools.ietf.org/html/rfc6066#section-3) in 2003.

Cloud Platforms

Google Cloud Functions is a similar product offering to Google App Engine, with many similarities, including allowing developers to run custom code behind the same domain: cloudfunctions.net.

Amazon Souq is a subsidiary of Amazon acquired in 2017. The website offers much of the same products as Amazon, and now has mostly been rebranded with the main Amazon brand, but retained a distinct domain called cms.souqcdn.com. This domain was used for a content distribution network (CDN), which mirrored static website assets such as images to be physically closer to users, enabling faster data transfer rates.

Implementation of Domain Fronting and the Use Case of Signal

Common censorship mechanisms employed by Iran, the United Arab Emirates, Turkey, and others is SNI filtering and domain name server (DNS) filtering. While the specific implementations of these censorship models are beyond the scope of this paper, both involve inspecting packets as they flow from the user to servers, checking for specific information, typically the “Host” denoted in the SNI tag, as well as any information for plaintext HTTP. This is a “cheap” censorship: filtering in this manner is computationally cheap, meaning users will typically not see a huge decrease in internet speeds, and monetarily cheap, as it is easy to implement with off the shelf solutions. For example, Turkey employed both SNI filter and DNS filter in late February 2020, blocking Facebook, Twitter, and Instagram (https://netblocks.org/reports/social-media-blocked-in-turkey-as-idlib-military-crisis-escalates-r8VWGXA5) during the incursion into Idlib.

Domain fronting can bypass SNI filtering and DNS filtering, because HTTPS requests wrap the plaintext HTTP information with TLS. similar to a letter with one return address on the outside, but containing another envelope with a different return address on inside. In this analogy, the return address on the outside might be google.com, while the return address on the envelope contained would say signal.org. Here, this “return address” is the Host header within a HTTP request. Because the censor cannot open the envelope due to the cryptographic guarantees provided by TLS, it must decide whether to censor the outer envelope entirely, thereby blocking google.com, or allow the letter to pass through.

Furthermore, domain fronting can be used by any actor from any Cloud Platform, as long as the CDN or the cloud platform is not completely blocked. Because of this, domain fronting through Google Cloud Platform is not available in the People’s Republic of China, due the complete block on google.com.

Signal first outlined their usage of domain fronting in December of 2016 (https://signal.org/blog/doodles-stickers-censorship/), utilizing domain fronting from Google App Engine, or appspot.com. This presented most censors with the choice to either block a large portion of Google traffic and potentially render Google Services unusable. However, Google later announced that it was shutting down domain fronting (https://github.com/signalapp/Signal-Android/pull/7584).

In digging into the Signal Android and Signal iOS code, we can see that the problem was resolved as of commit https://github.com/signalapp/Signal-Android/commit/9aed2343c141b1b3809f7eaccce61c22e342fda7, with an amusing commit message of “Attempt to resolve connectivity problems for some users”. Notably, the SignalServiceUrl has been appended with specific sections for Egypt, UAE, Oman, and Qatar. In changing from the cms.souqcdn.com to google.com, it is clear that Signal is now using domain fronting via google.com.

However, as noted above, Google shut down the capability to use domain fronting in 2018. It becomes clear upon further digging that the SERVICE_REFLECTOR_HOST constant has changed from europe-west1-signal-cdn-reflector.cloudfunctions.net from textsecure-service-reflected.whispersystems.org. In digging into the iOS version of the Singal application, this constant is defined as censorshipReflectorHost, which is then called within https://github.com/signalapp/Signal-iOS/blob/13a69e3af350f77e3abb4f6c85b9229e4dc4cf3d/SignalServiceKit/src/Network/OWSSignalService.m#L243, a portion of code that specifically calls for the HTTP “Host” header.

What now?

While cloudfunctions.net is a Google domain and presents most of the same challenges for censors as blocking google.com, it is conceivable that censors could filter cloudfunctions.net by restricting access to certain functionality within Google Cloud Platform. Cloud functions are one of the many products offered by Google Cloud Platform, and, as in the case of China and Amazon Web Services, Amazon does have a special version of Amazon Web Services made for the Chinese market (https://www.amazonaws.cn/en/), which includes different functionality and products. This means that, at some point, these Middle East countries could ask Google to comply by restricting the product offerings.

However, domain fronting remains an effective way of circumventing censorship by masking network traffic. Even if this particular domain fronting endpoint is shut down, it would be a matter of time before another domain was found, as in the case of Signal moving from Google Cloud Platform to Amazon Web Services, and back to Google Cloud Platform once again. Further attempts to crack down on domain fronting would see Signal move to Microsoft Azure, or even Alibaba Cloud.