5 ms·

The SNI is encapsulated in an outer layer of TLS, which is removed before forwarding traffic to Signal. That's what nginx-terminate is doing.

southerntofu 6y ago
The header will appear in plaintext between the user and the proxy (easy to detect/log/drop for their ISP/government), and still appear in plaintext between the proxy and Signal (which is less of a problem). The SNI header is not dropped to upstream because it's used whether the reverse proxy is operated by the intended recipient (Signal) or not (the proxy). That's precisely the reason why people have been promoting Encrypted SNI for some time now.
- quasirandom 6y ago
  It is not true that Signal domains are visible in plaintext on the wire between the user and the proxy. You can spin up the proxy and check yourself. Alternatively, you can ask yourself "why go through the trouble of setting up a legitimate ca-signed certificate if Signal domains are already leaking in plaintext"? The whole point of the ca-signed cert is to make the traffic blend in. Why go through that trouble when a simple regular expression could identify it?
  - southerntofu 6y ago
    > You can spin up the proxy and check yourself. I just did, and you are right. I stand corrected, sorry for spreading FUD. Other criticism of Signal still applies. I would edit my original message to reflect that, however i can't because it's been posted a while ago. An attacker (such as the government) may not drop connections in real-time to Signal proxies without considerable efforts (i.e. for every HTTPS stream, verifying whether the remote server is a Signal proxy). However, after passively recording SNI headers, the attacker check those remote servers to figure out whether they are Signal proxies. As a conclusion, this Signal proxy is an effective censorship-circumvention tool, but does not protect users from the consequences of circumventing government censorship (which may be harsh). A possible mitigation would be to have the virtualhost terminating the outer TLS connection serve the reverse proxy only from a specific folder/location, which cannot be well-known. So the attacker would see you are connecting to https://proxy.example https://proxy.example, but as long as https://proxy.example https://proxy.example serves legit-looking pages on /, and the Signal proxy is served from https://proxy.example/foobar https://proxy.example/foobar, the attacker may not passively discover the actual reverse proxy. Of course, every Signal proxy would need to use a different subfolder.

southerntofu 6y ago

The header will appear in plaintext between the user and the proxy (easy to detect/log/drop for their ISP/government), and still appear in plaintext between the proxy and Signal (which is less of a problem). The SNI header is not dropped to upstream because it's used whether the reverse proxy is operated by the intended recipient (Signal) or not (the proxy). That's precisely the reason why people have been promoting Encrypted SNI for some time now.

quasirandom 6y ago
It is not true that Signal domains are visible in plaintext on the wire between the user and the proxy. You can spin up the proxy and check yourself. Alternatively, you can ask yourself "why go through the trouble of setting up a legitimate ca-signed certificate if Signal domains are already leaking in plaintext"? The whole point of the ca-signed cert is to make the traffic blend in. Why go through that trouble when a simple regular expression could identify it?
- southerntofu 6y ago
  > You can spin up the proxy and check yourself. I just did, and you are right. I stand corrected, sorry for spreading FUD. Other criticism of Signal still applies. I would edit my original message to reflect that, however i can't because it's been posted a while ago. An attacker (such as the government) may not drop connections in real-time to Signal proxies without considerable efforts (i.e. for every HTTPS stream, verifying whether the remote server is a Signal proxy). However, after passively recording SNI headers, the attacker check those remote servers to figure out whether they are Signal proxies. As a conclusion, this Signal proxy is an effective censorship-circumvention tool, but does not protect users from the consequences of circumventing government censorship (which may be harsh). A possible mitigation would be to have the virtualhost terminating the outer TLS connection serve the reverse proxy only from a specific folder/location, which cannot be well-known. So the attacker would see you are connecting to https://proxy.example https://proxy.example, but as long as https://proxy.example https://proxy.example serves legit-looking pages on /, and the Signal proxy is served from https://proxy.example/foobar https://proxy.example/foobar, the attacker may not passively discover the actual reverse proxy. Of course, every Signal proxy would need to use a different subfolder.