Hacker News Reader

> If I'm looking at a congressman's voting history, is there a real benefit to that data being transmitted via an https session vs. http?

Yes.

Say you're a fan of Party A, and you'd like to find out whether your congressman voted the way that you like on some issue. Wouldn't it be a shame if your ISP was a fan of Party B, and tweaked the page in-flight to show you the voting results that you were hoping for, instead of what really happened? Or if some other organization found a way to inject some JS into the page to do that? For that matter, maybe Party A did it because they wanted hide a vote he had to make that they know might anger his supporters, but they'd rather have another Party A guy in Congress, even if he isn't perfect, than risk losing the seat to Party B.

Think all of that is paranoid nonsense? Well, pretty equivalent accusations have been thrown around in this election cycle by both sides, many by very mainstream organizations. I don't know that anything like this has happened, but it doesn't seem quite so crazy these days to say that it very well could.

Like many, you are forgetting the other half of what TLS provides. It's not only confidentiality, it's also authenticity. It ensures not only that nobody can eavesdrop the connection within the browser and the server, but also that nobody can modify it, for instance to inject a piece of Javascript with a browser exploit.

He's not necessarily "forgetting" it and I wish HTTPS-everywhere advocates would stop ascribing forgetfulness or bad motives. Some of us have a different opinion based on our own genuinely-held beliefs.

Requiring HTTPS everywhere is weighing certain factors above others. For many people, encryption and consequent lack of snooping/MITMing is an absolute which outweighs all other possible factors. That's fine. You're entitled to hold that belief. But please don't accuse others, who don't hold that as a trumps-everything absolute, of "forgetting" or (like the guy upthread who said "You being against HTTPS everything, is the same as being in support of MITM attacks somewhere") arguing in bad faith.

>Some of us have a different opinion based on our own genuinely-held beliefs

Such as?

Browsing a website with an adblocker in a public place may literally give me a virus.

That's what HTTPS everywhere protects against.

Browsing any infected website, HTTPS or otherwise, may give you a virus.

Right, but if it's HTTPS, only the website can give you a virus. If it's HTTP, the website can give you a virus, plus the owner of any network device your requests traveled through on the way to and from the website. That's often a lot of owners.

But he did forget the integrity benefits in his post. I understand that some people have different views, but if someone overlooks a significant point, it is ridiculous to get offended when someone else points it out.

I thought I addressed that in a couple of different ways, but no I didn't forget.

I'm not saying that TLS doesn't have benefits. I'm just saying that a blanket policy is a bad idea for the US Government. If the policy for secure connectivity was "support-but-don't require" or "make your best effort to support" it would make more sense to me.

It's just basic connection integrity -- without HTTPS, there's no guarantee the user is actually getting the content that the site meant to send, and vice versa. Those kind of attacks really do happen, and at scale (e.g. Verizon XUID, or China's Great Cannon).

If it's at all interesting, I laid out in detail, with examples, why I've been comfortable taking a very hard line on deprecating HTTP:

https://konklone.com/post/were-deprecating-http-and-its-goin...

> And let's face it - browser warnings about bad certificates are generally ignore

That's getting harder and harder to do. Doesn't Chrome require you to find three hidden buttons and enter a password to ignore the warning?

> Should I really have to pay someone to find out if a car has been used as a rental car or in an accident?

I don't follow... You don't need a certificate and the site can get a free one from LetsEncrypt

> If I'm looking at a congressman's voting history, is there a real benefit to that data being transmitted via an https session vs. http?

... not yet :)

But yes, it may allow to make certain conclusions regarding your interests, maybe your place of residence etc. But the larger idea here is to get users and the infrastructure accustomed to encryption. Chrome and Safari, for example, are moving towards treating any non-encrypted site as a security risk. That only works if the overwhelming majority of sites actually are encrypted, or it will just annoy people.

> There's a layer of complexity in the way that isn't necessary or helpful

which is motivation to improve the tooling. With LetsEncrypt the whole process has already become much easier. It's only a matter of time until SSL just works, the same way lots of other protocol negotiations invisibly happen today. > What happens when we're accessing data from a custom device with minimal resources

They'll have slightly less-minimal resources. SSL really doesn't require a Cray anymore. IoT-devices without encryption are a privacy nightmare, anyway. Some of them actually have access to extremely sensitive data or, even worse, can control critical hardware – c.f. pacemakers.

> And what happens when a guy working a low level office wants to expose a web service for something like viewing an event calendar?

He'll use google calendar, same as now. People who can't configure SSL have no business exposing services to the internet.

Use case that's pretty clear:

Many government websites provide a way to contact the government, either through address, email, or phone. An attacker can MITM the HTTP connection and replace that contact info with whatever they choose.

People place an incredibly high amount of trust in the government and what the government asks for, so every incoming call would have a >50% chance of resulting in complete and total identity theft.

If I can MITM your http connection, I can MITM your https connection.

But again, I'm not saying that there are no benefits to TLS, just that a blanket policy requiring TLS for _every_ government web service is a bad idea. One that prefers TLS or a best-effort-to-support TLS policy would make more sense.

Look at the history a bit. InCommon's use of insecure hashes required that all clients re-issue their certificates in order to avoid browser warnings. At the University level that was impractical to do quickly. At a federal government level? That's a whole different beast.

And look at heartbleed. How long did it take the federal government to make all resources secure again? Is it actually a completed project?

There's operational overhead to consider. There's the fact that MITM for http is minimally different than https. There's the plain and simple fact that a lot of data simply does not need to be secure. And there's the fact that there are already existing problems with making data available to the public at large.

If you want to provide confidence in government data, you could say that all certificates used by government resources are secured by X,Y, and Z certificate authorities and that would be a legitimate benefit.

"There's the fact that MITM for http is minimally different than https." Unless I'm missing something important, that can be prevented with key pinning.

Key pinning is not even needed. Entire point of SSL/TLS is to ensure end to end authenticity and confidentiality.

I believe the above poster does not fully understand SSL/TLS at all.

> Entire point of SSL/TLS is to ensure end to end authenticity and confidentiality.

The point is that country A can strongarm a certificate authority under their domain to sign any certificate they want. So if A wants to MITM google or github they can, and there's no way for you to know which certificate is the real one and which is the fake.

Key pinning could do a little towards preventing MITM, but implementing it is dangerous - in fact the whole standard is dangerous. Smashing Magazine went live with it, then had a cert expire before their max-age header did - rendering their site unavailable to repeat visitors. Then there are attacks like pkpransom to deal with, or the fact that Chrome doesn't implement hpkp properly.

Only ~400 sites actually implement pinning. It's going to be more of a security problem than a security solution in the next couple of years.

>If I can MITM your http connection, I can MITM your https connection.

No you can't, that's the whole point of public key encryption. Someone could give you every single byte, in order, from the entire two way negoatiation process, and you would still not be able to to MITM your way into the datastream unless you either reverse engineered both party's secret keys that are used to perform the {sender locks lock, send locked data, receiver counter locks, sends doubly locked data back, sender unlocks, send counter-locked-only data, receiver counter unlocks, receiver now has the original data} step. Unless you know BOTH keys that were used in the purely local locks, you can do exactly nothing at all despite seeing every single naked byte involved.

Can you MITM it if you already know the keys? Of course. But that is not an argument against HTTPS, of course. Can you guess or compute the keys if you don't have them? Given enough time, again: of course. Can known shortcomings in a known cypher make the job of computing keys easier? third time: of course. And that's why HTTPS lets you specify which "secure, today" cyphers to use, and which "no longer, or never secure" cyphers you will absolutely not accept. HTTPS with sha-1 was very secure years ago, for instance. Today it's a stupid choice if you want to remain secure, because its too easy to break.

HTTPS makes MITM "the least possible" by using a secure symmetric encryption for both parties to agree on which asymmetric encryption to use. And it lets parties agree on stronger and stronger cyphers as time goes on, so that the integrity of connections stays a moving target. MITM is a theoretical possibility, but unless you literally own a half-a-billion dollar supercomputer capable of factoring large primes in a reasonable amount of time, can you, personally? Plain and simple no.

> No you can't, that's the whole point of public key encryption.

.

> but unless you literally own a half-a-billion dollar supercomputer capable of factoring large primes in a reasonable amount of time, can you, personally? Plain and simple no.

I'm not sure if you're being purposefully dense, if you really don't know how easy it is, or if you place too much trust in the chain of resources required to make an SSL connection.

1. Key pinning.

2. Certificate transparency

3. Can't do it "accidentally". That's why a lot of people have 2 foot high fences, not that you can't jump over them but to create the atmosphere that this is private, and if you get caught there you can't say "oops".

4. Non-government (malicious router) can't MITM.

1. key pinning wasn't part of this policy, and regardless implementations are few and doing it correctly is problematic at best.

2. Certificate transparency is not implemented in all clients (and won't be).

3. I do understand the 2 foot high fence, and I've re-iterated repeatedly that I don't believe that TLS is a bad idea or that it provides no benefits. My original comment was meant to point out that a blanket "https everywhere" policy for the federal government is a bad idea.

4. malicious or friendly routers can MITM. Would you go to defcon, attach to an unknown wifi source, and pass your banking credentials?