Hacker News Reader

Comment by maaaats | Hacker News Reader

> The effect on those without computers at home

The additional bandwidth is not really that big. Yes, you cannot cache the big news-papers etc. when everything is https, but I think most stuff people do nowadays is things that's not cache-friendly anyway (like your private e-mail, facebook etc.). If they are afraid of some people using all the bandwidth because they cannot block youtube, netflix etc., they can can divide the traffic in better ways, limiting each client.

> Restricting the use of HTTP will require changing a number of scientific analysis tools.

A non-argument. One cannot let things remain the same for ages just because of backwards compatibility.

> HTTPS is not a security improvement for the hosts.

So what?

> HTTPS is frequently implemented improperly

Non-argument. Https not being perfect doesn't mean it's useless.

I'm not necessarily saying https-everywhere is a good idea, just that these arguments adds nothing to the discussion.

View on HN

> I think most stuff people do nowadays is things that's not cache-friendly anyway

So you're OK with throwing away a perfectly fine and proven internet protocol which has survived for several decades, on a vague notion you have that "it's probably not that cache-friendly anyway".

That sounds solid.

> HTTPS is not a security improvement for the hosts. So what?

Reduced performance. Increased latency. Increased complexity. Increased attack-vector size. But indeed: so what?

> HTTPS is frequently implemented improperly. Non-argument.

Yes. Who cares about the real world, anyway?

I'm awfully sorry, but I honestly don't think your post counts as a very good counter-argument to those very valid points which were raised in the reported issue.

> So you're OK with throwing away a perfectly fine and proven internet protocol which has survived for several decades, on a vague notion you have that "it's probably not that cache-friendly anyway".

Don't do straw men, please. I said that it's not as big an issue as the author said it was. Nothing more, nothing less.

> Reduced performance. Increased latency. Increased complexity. Increased attack-vector size. But indeed: so what?

Not that much increased complexity in most cases. But the performance is a potentially good argument. The author should have used that instead.

>So you're OK with throwing away a perfectly fine and proven internet protocol which has survived for several decades, on a vague notion you have that "it's probably not that cache-friendly anyway".

HTTPS is not throwing away HTTP. It just protects it with TLS.

>Increased attack-vector size. But indeed: so what?

I think you meant 'decreased'. By not being able to modify the payloads or steal cookies, attackers are only left with the TLS protocol to try to mess with, which is a much smaller attack vector than being able to tweak HTTP headers and so-on.

> I think you meant 'decreased'.

It could have been a sideways glance at flaws in SSL/TLS that have rendered servers, data, or both compromised. Basically, a straw-man claim that plain text is actually more secure, since a flaw in the crypto stack could exist.

> HTTPS is not throwing away HTTP. It just protects it with TLS.

Actually, in the issue that is linked the real problem is that HTTP is to be discarded in the government.

Just how much cacheable content do you suppose lies in RESTful messages? I think you have significantly misunderstood the use case for REST. All that performance stuff you bring up applies to CDNs, but not API requests.

It doesn't seem to me like you grasp the real world. There is a bit of a disparity between how we handle static content vs. dynamic API calls, and you demonstrate a willingness to conflate them repeatedly in this thread. It's baffling.

Additionally,

> HTTPS would hide attacks from existing intrusion detection systems.

is completely wrong. Intrusion detection systems are usually checking traffic between the reverse proxies and the servers where traffic is not encrypted.

There are quite a few problems with his post and it makes it appear that he has an agenda rather that genuine concern.

There's also a danger in users who will think that because the web is all "encrypted" now that must mean it's "safe", which will simply not be true.

Additionally, it makes website-owners beholden to the CAs (and I know they're already beholden to domain registrars but that's not really a good argument against adding an additional, arguably unnecessary cost to someone who just wants to run a hobby website.)

and I know they're already beholden to domain registrars but that's not really a good argument against adding an additional, arguably unnecessary cost to someone who just wants to run a hobby website.

You are not required to have a domain to have a website; just using an IP address works fine too, and - more importantly - unlike what would happen if the proposal to ban plaintext goes through, browsers don't give big scary warnings if you use an IP instead.

First, remember than the ban is only for .gov sites, so hobby argument is irrelevant here.

That said, Firefox does give a "scary warning" if you use an IP.

Don't get me started.

We had an internal dev' server. We generated a certificate for the IP address using our internal CA. We installed the internal CA on client machines+inside Firefox, Chrome and IE worked perfectly, Firefox bounced the IP address "domain" certificate even though it was valid by all metrics we could measure. It just claimed that the IP address of the host and the certificate's CN weren't matching even though they were. We tried it as the alternative name also, no dice.

We finally had to assign the machine an internal domain name using our DNS servers and redirect from the IP address just to fix Firefox's HTTPS issues with IP addresses. It is damn stupid and no other browser acts this way.

> There's also a danger in users who will think that because the web is all "encrypted" now that must mean it's "safe", which will simply not be true.

As I remember it, the proposal for mandatory opportunistic encryption was that it'd still be the http:// scheme with no padlock, so no expectations are set but some benefit is there.

>A non-argument. One cannot let things remain the same for ages just because of backwards compatibility.

A non-answer. We have done just that for ages, which is why dual core gigahertz processors with gigabyte of ram started up in 16 bit real mode (I don't recall if they do anymore) long after nobody used 16 bit real mode.

> > The effect on those without computers at home

> The additional bandwidth is not really that big.

It's actually not so much about bandwidth, it's more that if they don't have a computer at home they will have to use a computer at a library that forbids all HTTPS, making the resources unavailable.

> A non-argument. One cannot let things remain the same for ages just because of backwards compatibility.

So you volunteer to migrate and maintain all the software we're talking about here, or to pay the people that will do it over the decades to come ?

Migration doesn't come out of thin air by simply snapping fingers. Yes, the software is old. Yes, it's ugly to see. Yes, it's hard to maintain. But, if you read the article, you would no that there is no funding to maintain it, so they're doing what they can with what they have. Everyone would love to use the cleanest, leanest, UNIXest tech stack, but the realities of the world make it far more difficult than what we're used to see on HN.

Regarding old software, I'd say the problem is being overblown. You don't need to touch any of them. If the service is HTTPS only and the client is HTTP only, the obvious solutions is to have a proxy in the middle, converting between the two.

For example: "Stunnel is a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs' code."

https://www.stunnel.org/

The kinds of projects and organizations that will suffer the most from forcing HTTPS are ones like those under government research umbrellas which require vast amounts of paperwork to do something as simple as setup an SSH key so rsync can be used. That pales in comparison to the amount of paperwork required to do something like install a new piece of software or setup a new server. On top of that, such changes are not budgeted for, so you end up with highly educated and trained people, who ought to be doing their research or actually making progress in their work, spending time fixing artificial problems that ought to be handled by dedicated staff. This wastes taxpayer dollars and leads to personnel burnout.

Why? All because some memo-writer in Washington said, "There's no such thing as insensitive web traffic!"

It's easy to make these proclamations when you have no part in fixing the fallout.

> It's actually not so much about bandwidth, it's more that if they don't have a computer at home they will have to use a computer at a library that forbids all HTTPS, making the resources unavailable.

That's a weak argument. If places like Libraries continue to block all HTTPS content, before long they would have blocked so much of the internet that the entire service would lack a coherent point.

Most sites in the top 50 are HTTPS only now. How long until they all are?

That's what I was thinking too reading the article. At least half of his points are non-arguments and and the other half is stuff like "but we've always done it this way! why change that?!"

Please. Don't forget you can actually be infected with malware through plain-text connections. It's not just a privacy thing.

Reply on news.ycombinator.com