Hacker News Reader

Comment by closeparen | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com