Hacker News Reader

Comment by altendo | Hacker News Reader

[1] answers it clearly:

> With today's release, domain fronting is enabled for Signal users who have a phone number with a country code from Egypt or the UAE. When those users send a Signal message, it will look like a normal HTTPS request to www.google.com. To block Signal messages, these countries would also have to block all of google.com. (emphasis added)

It can be blocked, but doing so will block google.com. Basically Open Whisper Systems is making a block that much more costly to implement, since Google is ubiquitous in so many different areas.

EDIT: forgot how to add the emphasis, is fixed now.

View on HN

It can be blocked, but doing so will block google.com. Basically Open Whisper Systems is making a block that much more costly to implement, since Google is ubiquitous in so many different areas.

If they can ramp up their homegrown options or a regional competitor to Google develops that can really compete well, why wouldn't they block all of Google.com? In China, it's already happening. It's completely possible because a lot of the population doesn't require access to English content, and so doesn't require an English search engine. Local search engines like Baidu and foreign search engines willing to comply with their local laws like Bing will be totally fine. And given that the Middle East has a lot of locals who don't actually speak English, I see that as a distinct possibility in the future. The comparison is almost perfect, no?

You're missing the point. Domain fronting is intended to mask the Signal traffic into something that's not.

Sure, they can block Google. Signal can do the same process with YouTube, or GMail, or whatever, and they can play a cat and mouse game like that until Egyptian people get really pissed off.

This comment explains better than I can as to why that doesn't matter. https://news.ycombinator.com/item?id=13268819 Essentially, if a local regional player (or a foreign player who complies with their laws) can compete to take the place of whatever domain they block, why can't they block any or all domains used for domain fronting? The cat and mouse game becomes irrelevant if local companies become relevant.

Why isn't all HTTPS traffic being declared this way (hiding the real endpoint)? Is there any downside doing this?

SNI requires the hostname to be sent over the wire as plaintext. The reason why SNI is useful is because it allows one server to host many HTTPS domains. Perhaps some innovation to SNI would fix this problem.

https://en.wikipedia.org/wiki/Server_Name_Indication

This. The current advent of the encrypted web would not have been possible without SNI - the costs for exclusive IPv4 addresses (especially when using a CDN) would have been prohibitive.

SNI isn't as much as a security risk if you consider that before resolving, you usually need a DNS request too - which would expose the endpoint to your ISP anyway.

The server doesn't know which certificate to present to the user unless the user provides some hint as to which endpoint is desired.

This only works because the same company is hosting the content (appspot) as the fronting domain (google.com). Google terminates the TLS then looks at the host header to see where to send it.

I couldn't hide my website behind facebook, because my website and facebook are not behind the same TLS terminator.

How did they manage to accomplish this? Did they need cooperation from Google to do this, and to what extent?

They're hosting a proxy on appspot.

Can you really not draw a distinction between appspot and google.com? They run googleusercontent.com to maintain that separation for Google Cache, after all.

Not unless you MITM the connection, otherwise it wouldn't be an effective measure.

There's a pretty good write up I found here:

https://trac.torproject.org/projects/tor/wiki/doc/meek

commit for the ios version is here:

https://github.com/WhisperSystems/SignalServiceKit/commit/78...

Thanks for the links, informative. So the proxy app that the Egypt government would like to take down is

  signal-reflector-meek.appspot.com

No, per the linked check-in, the Egyptian govt would have to block OWSCensorshipConfigurationFrontingHost, which is "https://google.com". That is the domain looked up in DNS and included in the TLS Certificate's SNI field. These are the only domains that are sent plain-text.

"signal-reflector-meek.appspot.com" domain only shows up in the HTTP "Host" header, which is TLS encrypted, and thus not visible to the censors.

That's only for cookie/XSS purposes. It still runs from the same server farm, so you can do things like this:

    $ curl -H 'Host: xss-game.appspot.com' https://www.google.com/
    <!doctype html>
    [...]
    <title>XSS game</title>

This works for all the AppSpot hostnames I tried (even my own), but not for any custom domains.

At brute force they will do as Turkey has done with YouTube, and order the ISPs to null route entire /20 to /16 sized pieces of the internet belonging to YouTube, etc. Same with appspot.

In most cases you could, but due to how google implements TLS termination, google ignores the SNI domain when considering what content to send, it only pays attention to the host header.

Seems like even more effective than fronting as google.com would be essentially to front as a random domain, perhaps selected from the top 1k domains popular in that country...

To boot: Systematically defeating the ability for a country or ISP to block traffic to a specific domain would be a universal win for free speech.

This only works because the same company is hosting the content (appspot) as the fronting domain (google.com). Google terminates the TLS then looks at the host header to see where to send it. It can't be hidden behind a random domain.

Should have made it the website of the government :D

This only works because the same company is hosting the content (appspot) as the fronting domain (google.com). Google terminates the TLS then looks at the host header to see where to send it.

Reply on news.ycombinator.com