Hacker News Reader

Comment by CHY872 | Hacker News Reader

> Wrong. Passive eavesdroppers. Pay attention.

If you're in a position and have the motivation to passively eavesdrop, you probably have the hardware to actively eavesdrop as well.

> Wrong. AES-NI and the fact that Google uses it should be proof enough. This used to be true, but isn't anymore.

Pure garbage. For example, Netflix saw a 50% capacity drop on their servers by enabling TLS [0].

Google do it because their content is more dynamic, so TLS isn't much in the way of extra demand. If you have mostly static content, the overhead of TLS is pretty much all your overhead.

[0] - https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf

View on HN

> If you're in a position and have the motivation to passively eavesdrop, you probably have the hardware to actively eavesdrop as well.

Targeted, yes. Wholesale, no. When I said pay attention I was referring to the fact that in a post-Snowden world the fact that people do this is not even secret any more.

Edit: I'm new to HN and don't know why the reply button is missing, but I think you and I have different definition of the word "wholesale". But in any case it's beside the point, since if someone sniffs all Atlantic cables they can see exactly what I do on US servers, while they will only see hostnames and some side channels if it's all SSL.

They will not MITM all SSL connections with a forged cert, just to create a dossier on every living human to be retrieved later if they become "interesting". They will if it's HTTP and you can do it passively.

No, it can be done wholesale. For example, a corporate firewall of the kind used in any large business will happily (and cheaply) MITM every TLS connection that goes through it. It'd be easy for an ISP to install such a device for unsigned certs, if the payoff were great enough.

ISPs have incentives too (advertising, user tracking, etc).

You are absolutely right that corporations do this. It's important to understand how this is happening though. In order to do so, they must add their own Certificate Authority to your browser so that it accepts a certificate signed by a non-root Certificate Authority as valid. This is easy to manage at a corporate level thanks to things like Active Directory that allow you to install root CA's in the browsers of your domain users. It is far more difficult for an ISP to install a non-root CA in your browser, therefore mitigating this risk.

> Pure garbage.

From your link: "The servers are also designed to deliver between 10Gbps and 40Gbps of continuous bandwidth utilization"

So how many terabits per second are you pushing out? Oh… oh you're not? You're not network bound at all? Well then…

And for reference: https://www.entrust.com/ssl-is-not-computationally-expensive... https://devcentral.f5.com/articles/dispelling-the-new-ssl-my... From 2011

> Google do it because their content is more dynamic

Isn't Youtube SSL?

My point was designed to illustrate that TLS can be in some cases found to have considerable overheads in certain applications. For example, delivery of static content.

I'm not saying that it's relevant in most cases; but saying that the overhead of TLS is minimal is factually incorrect - in some relatively common cases it is anything but.

If a company like Netflix says that it'd cost them >$100M per year to deliver their already encrypted content using TLS (recently they've got those costs down, but they still say it's expensive), I'm more inclined to listen to them saying that TLS has real costs (because they've done the analysis) than you saying it doesn't.

Netflix aren't the only ones. It's CDNs in general - a modern processor will decrypt and encrypt AES at about 1Gbps per core; meaning that you're talking about (for a high-throughput server) needing a lot of compute in addition to a lot of ram.

I'm sure that it can be worked around (Cloudflare apparently worked with Intel to optimise their version of OpenSSL), but certainly what Google or Cloudflare do won't necessarily apply to what everyone else does, and Cloudflare's not exactly known for serving large files.

Again, this is more a 'don't assume what works for you works for everyone' and not at all a 'it's wrong in every case' type point.

Reply on news.ycombinator.com