4 ms·
> the overhead The computational overhead is negligible. This simply isn't a credible argument against HTTPS. Netflix send petabytes of data over HTTPS. There
by MaxBarraclough 7y ago
> the overhead
The computational overhead is negligible. This simply isn't a credible argument against HTTPS.
Netflix send petabytes of data over HTTPS. There's no excuse for anyone else.
> A medical site is different to a static html site like listed in the post.
Different in degree, but not in category. Your browsing habits on ordinary non-sensitive sites can still be used to profile you.
> ISP regardless of SSL know which sites I’m visiting
They can still look at the destination IP, yes, and they can probably look at your DNS requests, as secure DNS is currently only rarely used. It's still worth doing. Knowing that someone went on Wikipedia tells you almost nothing. Knowing the specific pages they went to, tells you a great deal.
> It’s there in the HTTP host header regardless of SSL or not.
That's not the case. HTTPS encrypts all headers.
> transit security can easily be encrypted without SSL
The easy solution is HTTPS.
> people are too lazy to encrypt their content within the application.
A universal principle in cyber-security: rolling your own crypto scheme is generally a terrible idea. As I said, Steam and Apt are the exceptions; they use plain HTTP for delivery, and implement secure file verification using hashes. Even here, with competent people running a simple delivery scheme, there can be serious security issues [0].
When it comes to web applications, you cannot implement your own secure delivery, for the obvious reason: an attacker can just replace your code. Sites like LastPass.com still have to use HTTPS to deliver the web app.
Even if it could be done, there would be no reason to. The browser offers you HTTPS, so you get a carefully designed, battle-tested protocol, and a carefully designed, battle-tested implementation. You are entirely shielded from all the complexities. You aren't going to do better in JavaScript.
> When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration.
It's additional configuration work, yes, but I don't accept that it's much of an argument against HTTPs. You still have totally free choice over your tooling and languages.
> I don’t dismiss that HTTPS is important but I feel platform is flawed.
You've not presented a single good argument against the technical merits of HTTPS.
> Owned by corporate greed. It’s security based upon pay us money or else model.
You can get certs for free. This isn't new. [1]
[0] https://justi.cz/security/2019/01/22/apt-rce.html https://justi.cz/security/2019/01/22/apt-rce.html
[1] https://en.wikipedia.org/wiki/Let%27s_Encrypt https://en.wikipedia.org/wiki/Let%27s_Encrypt
- bityard 7y ago> Netflix send petabytes of data over HTTPS. There's no excuse for anyone else. Uhh, yes, indeed... manufacturing cars is so cheap these days, even General Motors can do it... > That's not the case. HTTPS encrypts all headers. That's not the case. HTTP uses SNI (for now): https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication
- MaxBarraclough 7y ago> manufacturing cars is so cheap these days, even General Motors can do it... Short answer: empirically, there's no question: HTTPS CPU overheads simply aren't a problem [0]. Long answer: that's disanalogous. Manufacturing works with economy of scale. Netflix have it worse than the rest of us. They have to deliver tens of gigabytes per month per customer, using roughly the same hardware as the rest of us. According to that Ars Technica article, they did their usual Netflix-ey software optimisations with FreeBSD, but their hardware isn't customised for the job. Their scale doesn't much help them. If HTTPS overheads would put anyone out of business, it would be Netflix, but here we are: they voluntarily added HTTPS for their streams. Again, as I think it bears stressing: these guys are transmitting about 15% of all data-flow across the Internet. Out of all the HTTPS traffic in the entire world (measured by gigabytes, admittedly discounting number of connections established), Netflix handles at least 15% of it. They do so voluntarily. Same goes for YouTube. If you can think of a business model where HTTPS overheads would cause more trouble than they do for Netflix and YouTube, I'd like to hear it. > That's not the case. HTTP uses SNI (for now) Thanks, I wasn't aware of SNI. I don't think it gives much more away though, does it? Someone spying on my line can already see the IP address I'm connecting to. They already know I'm connecting to Wikipedia. They still can't see the specific page I'm requesting. SNI only leaks information where multiple sites are hosted on the same public IP, right? [0] https://www.keycdn.com/blog/https-performance-overhead https://www.keycdn.com/blog/https-performance-overhead
- bencollier49 7y ago> Short answer: empirically, there's no question: HTTPS CPU overheads simply aren't a problem [0]. That's incorrect. Plenty of people browse the net on Z80 based machines. HTTPS borks that, the computers aren't fast enough to run the decryption. There are a lot of assumptions being made in this conversation which may be quite inaccurate.