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

> 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.

> I would assume that the MITM proxy running on localhost also checks CAs, so what's the problem? (besides breaking cert pinning)

Superfish did not check CAs.

> OF COURSE not. They would just MITM it without crypto stuff. So… it would just be worse.

I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument).

> I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument).

That SSL interception on computers is on the rise is something every PC game developer can probably attribute to. Right now you cannot pin any certificates any more because of the widespread penetration of SSL intercepting firewalls and antivirus solutions.

>I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument).

I think the author is arguing that SSL requires active eavesdropping, which:

1.) Might break encryption (see Superfish), while the user thinks they're using proper SSL (author argued about the "false sense of security" in a separate section)

2.) Might just break things -- more an argument about software stability than privacy or security.

Huh. Well that's superfish. Surely the norm among big name AV is to check CAs? Or am I being naive?

> I think the author is arguing here that the MITM attack wouldn't bother with encrypted traffic (which is obviously a very weak argument)

That wouldn't be the case if it was all encrypted, so it's actually a counter-argument.

> Hello Mr NSA.

> I'm sorry I don't hate freedom like you.

...and you just destroyed your own argument with the ad hominems.

http://lmgtfy.com/?q=define+joke

>Hello Mr NSA.

Oh wow, way to start a constructive discussion.

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

Are you saying the cost of encryption is affordable for everybody because it is for Google?

> Are you saying the cost of encryption is affordable for everybody because it is for Google?

On top of that, it assumes everybody has the latest processors. In reality, people don't upgrade their computers every year.

Worse, it's people with older computers who need to eke out every bit of performance their processors offer. Like, sure, I can afford to burn CPU cycles because I have a Haswell i7, but someone with an old Core 2 can't, and they're the ones who will have to burn CPU on encryption, and I don't need to because my powerful CPU has AES-NI.

If you don't have AES-NI, then you don't have much traffic. Otherwise you would have bought newer servers. And you therefore don't have a problem either way.

I don't use encryption for media streaming on my Raspberry Pi because the lack of hardware support for crypto means the download rates drop from 70 to 7 Mbit/s. I won't spend money on the new model because people on the internet tell me streaming cartoon series is sensitive traffic.

There you go, a counterexample for your blatant overgeneralization.

:-)

I seem to remember getting 50-70Mbps with SSL on my Raspberry Pi (not RPi2). I had to tweak my cipherlist, but not to anything unreasonable insecure. The limiting factor there though was by far the USB hard drive attached.

Banana Pi has SATA onboard, and not a NIC that's attached over the USB bus, so I'd recommend that in most cases.

I wondered if I did anything wrong with the setup, so I'd be really interested in your cipher list. I did read some benchmarks on the internet though.

It was most likely upping the prio of RC4, to select that. It's been a while though.

On top of that, encryption adds client-side overhead as well.

Oh, I wouldn't really care about client-side overhead -- that one scales itself, and in my particular example the machines I use are powerful enough.