Hacker News Reader

Comment by kempbellt | Hacker News Reader

I agree. The intent is noble, but this headline makes Amazon look like the bad guy for disapproving unauthorized use of one of their domains, which is quite reasonable.

View on HN

Amazon and Google are certainly within their rights to refuse this. Allowing domain fronting is likely to put quite a lot of their money at risk, so this outcome is unsurprising, but it's still the less ethical one.

This might be the only possible outcome given a corporation's legal responsibilities to its shareholders etc, I don't know all that well enough, but I think it's still justified to lower my opinion of Google and Amazon because of this.

I realized I glossed over the fact that this would put other AWS/GAE customers's money at risk too. This complicates matters somewhat, and some (I believe a negligible number of) customers might switch to an unblocked competitor.

Personally this weakens my view a little, but is not enough to change it substantially.

The ethical choice is for AWS and Google to collude and both allow signal to continue to using domain fronting.

Great PR opportunity for Cloudflare to pickup the torch.

EDIT: Not supported by Cloudflare.

Cloudflare is against domain fronting https://arstechnica.com/information-technology/2018/04/googl...

Despite the use case for censorship circumvention, many malware command and control bots use domain fronting to bypass corporate web filters that otherwise might block their traffic. CloudFlare, being a security-focused CDN, most definitely does not want to help enable malware authors to bypass security.

Russia had no problem whatsoever blocking both of them when blocking Tether a couple weeks ago.

No problem? They crippled their own use of the internet, at huge financial cost.

Where do you get that from? The Russian government blocked lots of AWS and Google IPs, and had no problem keeping them blocked until they agreed to stop allowing this, which was the same thing Telegram was using. And it doesn't appear that they cared about the "huge financial cost".

the problem I'm having is that I'm not even sure this qualifies as 'use' really. sure they're putting the domain name in the tls handshake from the client side instead of their own. the handshake itself works the same, everything that happens after is the same. the tls enpoint on googles/amazons servers just makes sure the domain is in its list of known domains, nothing else depends on it.

Because they are the bad guy.

Hardly reasonable. Domains are (in reality, if not in legislative fantasy) property of ICANN and merely rented by everyone else.

So? If we qualify it to preventing unauthorized use of one of their rented domains does that make it any less reasonable?

The conceit here is that you must be "authorized" in order to write an app that puts the domain in question into the SNI field of a TLS connection that it initiates. I don't think that's reasonable.

It is of course up to Amazon what their servers then do when presented with such a connection, in particular whether they ensure the Host: header later presented matches the SNI data.

So have they obtained the permission of ICANN? I rent my home, but I still call the police if there's a trespasser.

Reply on news.ycombinator.com