Hacker News new | ask | show | jobs
by logicOnly 2087 days ago
One of my biggest complaints is how https flags text based websites for being dangerous.

What danger could possibly happen if I'm reading about a Physical Therapy clinic?

They don't take credit cards, there's no information for me to enter on the website.

But unless the Physical Therapist knows how to manage the server, they get this scary warning.

Maybe it isn't a big deal to US healthcare because they make lots of money. But I imagine there are others that don't have the technical abilities to upgrade to https. Could your grandma do it for her sewing store?

9 comments

Just because the original site was simple, doesn't mean that the thing an MITM replaces it with needs to be. Sites aren't apps; sites that do little don't "install" into the browser with an intentionally-limited set of permissions, such that an attacker would then be limited in their attack by those permissions. An MITM can replace the site with basically whatever they like.

I can't find the example (it was linked on HN a few years back), but a clear demonstration of this is a case where the MITM can serve a phishing page that initially appears to be the original site you've hijacked (so the user trusts it, and leaves it alone); but later, while the page is not visible (for example, when the user switches away from that tab), the page will switch over to showing a Facebook login screen or something.

Since the website isn't a known "malicious site" (so no alert from the browser), the user probably won't bother to look at the URL bar. They'll just think they left Facebook open in a tab, and it logged them out for inactivity. So they'll "log back in."

And MITM is still possible for https, just a bit different with two points of interception, rather than one, see my other comment [1].

[1] https://news.ycombinator.com/item?id=24711111

EDIT: what are the downvotes for? If for disagreement, this only shows how poorly people misunderstand security of https.

Grandma’s sewing store would be hosted on a VPS or Squarespace, and will have a checkbox to provision “secure site encryption” for her without any further work required on her part. (They may charge her money for the certificate, if they’re a scummy VPS.)

This ship has sailed, though: “plaintext HTTP” is available only with HTTP/0 and HTTP/1. This article is discussing HTTP/3, which carries forward the requirement of wire encryption that HTTP/2 argued over for a long time and then incorporated into the standard.

(Incidentally, my grandmother was a Smalltalk and 6502 assembly programmer of educational software in the 80s. She let me read her technical books at age 5. Probably best to find another example, such as “non-technical site owners”.)

https doesn't flag that.

Your browser might flag a http server as dangerous (mine doesn't - it just has a padlock with a line through), but you're leaking information to your ISP that you are reading about a Physical Therapist.

If your site tries to do https and fails (self signed or invalid certificate) it will rightly flag up that it's a problem.

My grandma would not be able to manage a server on the internet, let alone responsibly manage it. If you can't set up a modern server with https then you shouldn't be running a server on the internet at all.

Assuming your physical therapist has their own website with its own doman, and not just, say, a Facebook page, you're leaking that information to your ISP with https, too. https doesn't hide the domain you're talking to, just the specific URLs within that domain.
We have SNI. Now sure your therapist may run their own VM on it's own IP address, but that's not very likely.
SNI doesn't encrypt the desired hostname in the payload of the initial connection. It's still plainly visible to an eavesdropper. They can also observe un-encrypted DNS lookups.
Chrome and derivatives display "! Not secure" in the omnibar, which is presumably what they are referring to.
20 year ago the world thought that IE6 was synonymous with the internet

Thank god we moved on from that.

The problem is you can't trust what you're reading to be from the source. Maybe the site doesn't take credit cards. But after a MITM it might suddenly start taking credit cards. And other things. Whatever the attacker wants! All in the seeming name of the origin.
MITM like that still works for most https websites because of the automatic domain validation by ACME-based certificate authorities. The only caveat is that now an attacker has to get a valid certificate, so first he has to do MITM on the route from the datacenters where CAs run validators to the datacenter where the website is hosted, which for most websites today is likely a long route crossing many countries, after that an attacker gets the exact capabilities as with MITMing http.
No, you're forgetting about Certificate Transparency, which protects against this attack.
It doesn't. Pretty much no one monitors CT logs and for those who do there is no way to prove misissuance of domain-validated certificate and revoke it, they don't have private keys.
If you believe you have been successfully attacked this way you should report it, the logs would be part of your evidence. I spent some time looking for this sort of thing, and it does look like it happens sometimes, mostly to military or political targets, but it's rare. That work is owned by a previous employer, but let's say dozens of times across several years.

You are entitled to revocation of any unexpired certificates for names over which you can demonstrate control. For Let's Encrypt for example you can automate this, simply make the API calls to demonstrate control (as you would for issuance) and then present the certificate that is to be revoked (it's in the logs) and ask their API to revoke it.

But if an attacker can intercept domain validation to issue a certificate, there is little reason not to protect his own certificate from revocation by preventing subsequent validations until it is used on a target, if he can't hide this fact in some way of course. A report of that will look like someone is trying to revoke a certificate for a domain they don't control and won't actually solve the problem even if a human can be convinced by other method that you do control the domain.

Maybe DNSSEC could be used here to help if ACME added a way to force DNSSEC-only domain validation.

Feb 19, 2020: Multi-Perspective Validation Improves Domain Validation Security (https://letsencrypt.org/2020/02/19/multi-perspective-validat...)
That's the thing, they don't seem to bother actually addressing the problem and assume no other interception capability than hacking BGP. But we are talking here about exactly that, i.e. if you can intercept traffic in any other way somewhere close to a website or its nameservers - you can get a valid certificate and use it to MITM its visitors anywhere in the world where you can intercept traffic too. And in case of using big cloud providers for validation to "improve" security, this still likely pushes traffic from all of them through some big IX before reaching a datacenter with a website and at worst only adds a couple more points an attacker has to intercept traffic at to get the certificate.

This is where all that centralization is really bad for security. It basically makes https a protection only against low effort MITM of last mile ISPs.

https doesn't care about the content, it's the browser that tells the user that his communication is in the clear, and there's no assurance as to who the user is talking to.

> What danger could possibly happen if I'm reading about a Physical Therapy clinic?

Depends what is a "danger" to you. Your insurance learning you're having issues and deciding to increase the amounts you owe them, because they saw that your back is aching, is definitely a problem.

> But unless the Physical Therapist knows how to manage the server, they get this scary warning.

Wrong. In 2020, if the Physical Therapist can have an http website, they can have an https website with a valid certificate.

It's the same for your grandma store. Going from no website to http is a much much bigger step than going from http to https.

Using the same logic, https://facebook.com is also a danger, since we know they routinely sell out our personal data to advertisers and probably anyone who is willing to pay for them. Or an aquitance could be an insurance agent... Not to mention NSA as a source of danger in this sense.

The real danger I see is the disappearance of lots of quality, not-for-profit content that reminds me of the good old Internet, swapping it with new shiny https publishers, of which 90% belong to the same owners. That's the real danger to the society. The long tail is disappearing, while commercial interests, and the manipulation that comes with that sneaks in everywhere.

A real danger of not going with TLS is MITM attacks. Specifically, injection of hostile JS, CSS or whatever that can be used to penetrate your browser and/or local system.
HTTPS is free (with let's encrypt) and useful for privacy.

For example: No one is stopping someone from intercepting your request to your clinic and add a form asking for personal details - and then using those details to "restore password" - or simply ask for your CC number. You might not fall for it but are you as confident in all other patients?

> with let's encrypt

My biggest concern as http becomes less and less acceptable is that practically the entire internet relies on lets encrypt to run.

Not to run, just to keep running long-term. If Let’s Encrypt exploded you would have less than 30 days to get it running again. But that’s not such a short time.
Nope. https, hybrid crypto and pub->free CA's are the largest backdoor into internet traffic ever (accidentally) devised. The standardization on https for everything (including alt app protocols (dns,etc...)) is very apparently an info grab.

Sym crypto is the only answer (Schneier,DJB) people have been trumpeting this for years.

If I connect to a server via https and see it's certificate, I am confident that my communication is secure between me and the server hosting that certificate.

To validate the person holding that certificate is who they claim to be, how can I do that? By either getting their certificate out of band (impractical), or trusting an intermediate.

Lets encrypt doesn't make it any easier or harder to get an invalid certificate.

Now if the server wants me to authenticate, https has that built in. I can present my own client certificate, and if it's signed by somewhere the server trusts, it knows who I am. But how would a random server authenticate who I am? I'd personally rather use certificates or ssh keys or similar than usernames and passwords, but that's too complex for the average person.

Clearly I could have lost control over the key to my certificate, or the server could have lost theirs, there's not much you can do about that, no matter what type of authentication system you use.

It's not free when you need to pay someone to update your website.

Grandma might be able to edit HTML, but "what's sudo? What's ssh? This one website says I need to pay for certs?"

So what are you saying? That we should sacrifice security (as explained in sibling comments) in order to allow grandmas to create their own web pages?
It all sounds ageist and misogynystic to me. I work with a few grandmas who are right there on top of the newest technologies going. One is a scientist working on a hell of a cool cloud product. Old ladies aren't the model of stupidity, as this thread might lead someone to believe.
Yes, exactly. Grandma should be able to easily publish. Now grandma doesn't say anything because the unnecessary complication pushed by google (https and now http3 which might be enforced a few years later. These has little to do with security and performance; mostly the google ad business has any revenue from all these complications)
Grandma also pays her registrar and ICANN for the domain every year too. Free was never the price of having a website, and it's not a reasonable standard of expectation today. As is with literally anything else that needs maintenance, if you can't maintain it yourself, you have to pay someone else to maintain it.
There are a few areas of concern here:

First, getting authentic data from the provider so that you know what they published is what you're reading.

But also links and embedded links/scripts. Since HTTP can be (relatively) trivially MITMd, it not only exposes end users to getting manipulated info, but also, having them running Javascript that's not what the site owner intended.

In fact that's exactly how China attacked GitHub recently: https://threatpost.com/github-attack-perpetrated-by-chinas-g...

Yes. There is so much groupthink on this issue. Know that you are not alone.