Hacker News Reader

Comment by Klathmon | Hacker News Reader

I think you misunderstand. An ad-free website served over HTTP can (and does) have ads injected into it by someone along the way. And not just ads, but malware as well.

And privacy of information going from your browser to the internet is only half of the equation. What about privacy about what you are viewing?

I don't want every single router between my computer and the server knowing the full contents of the pages I'm choosing to view, or building advertising profiles on my habits, or even knowing what device type, browser, OS, and more I'm using.

View on HN

Ah, ok.

Would a self-signed (I'm not sure this is the right terminology) cert be sufficient for this?

That way if someone MITM'd you, you would see that the cert changed, right?

But I guess if the path you use to the website is always the same, then if they MITM'd you the first time you accessed it, you wouldn't be able to tell?

Hmm, I guess that probably isn't enough then.

Is there really no good way to serve public information from a website that doesn't require periodically updating one's cert, and without risking MITM'ers changing the content?

I guess if the client already has the hash of the content, but that isn't very convenient.

Huh.

I guess example.com needs https then?

They already serve example.com as both https and http. Try it: https://example.com/

They don't use HSTS to force it, because example.com isn't meant to anything but an example.

> Would a self-signed (I'm not sure this is the right terminology) cert be sufficient for this?

Yes, but browsers make that MUCH more scary than surfing insecure (not https) sites.

Self-signed certificates are trivially MITMable. In the absence of cert pinning (like SSH does), they offer no security.

The chicken and egg problem with self-signed certs is not solved by Lets Encrypt. It's simply a matter of who do you trust.

I can publish my personal CA certificate and ask you to trust it. This is hardly different than how I prove myself to Lets Encrypt.

Let's Encrypt has to use one of the Ten Blessed Methods to validate control over the name they issue for. Unlike a random person out on the Internet, doing that validation is their actual job, so they're pretty good at it, and the Ten Blessed Methods tell them what constitutes an acceptable means of doing so.

These days Let's Encrypt uses a "multiple view" approach in which more than one physical location in the world hosts Let's Encrypt systems (although only their US West Coast location contains the actual CA) and so they can check that things appear the same from more than one angle, you can't just take over the ISP they're getting service from in California and leverage that to get anything you want. If the views don't agree (e.g. you pass a Let's Encrypt validation from Paris but not from San Francisco) then your application is denied automatically.

Now, the next layer above is also interesting. Who checks Let's Encrypt and other public CAs are doing their job? Fortunately Mozilla are on the case again, all major Trust stores say they enforce the Baseline Requirements which explain how a CA should do its job, but all except one make decisions entirely in private. Or maybe they just bin all the complaints if the CA pays them a bribe? Who knows. Mozilla acts openly in public, you can (and indeed your insight might be valuable, so please do) help oversee the Web PKI in their m.d.s.policy group.

Assuming cert pinning is saving the information from the first time it is accessed, that is sort-of what I was imagining for part of what I was saying.

The problem with self-signed certs is that you're then given no assurance that you're not being MITMed. An attacker could be stripping the real SSL off a connection, re-encrypting it with a self-signed cert they've created, and then showing that to you. Real SSL certificates have trust chains, which aren't used in self-signed certs.

True. But why should the website owner do something about it? It's a crappy network the user is using. The same crappy network could strip https and then inject ads.

No, a properly setup site cannot have it's HTTPS stripped, and even if it could it is the browsers job to warn the user that they site they are on is insecure regardless of why it is that way.

https stripped or doesn't work could be achieved.

Problem is that browser warnings are sometimes false. Self signed certificates are not unsecure, the underlying encryption is still the same. The "unsecure" only applies to the CA, but that is not clear in the warning.

>Problem is that browser warnings are sometimes false. Self signed certificates are not unsafe, the underlying encryption is still the same.

Browser warnings aren't false, you're reading of them is false. Read around on badssl.com [0]. The self-signed warnings in chrome say:

>Attackers might be trying to steal your information from self-signed.badssl.com (for example, passwords, messages, or credit cards).

And when you click advanced chrome says:

>This server could not prove that it is self-signed.badssl.com; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.

It says nothing about the encryption being bad, I don't know where you got that from. What it does say is that Chrome has no way to validate that the site you are going to is actually the site in the address bar. Encryption is pointless if anyone and everyone knows the password (oversimplified, but you get the point). Encryption without Authentication is as secure as normal HTTP.

[0] https://badssl.com/

Because of the term "unsecure". Also Chrome says "This is not a secure connection". Emphasis on "connection". Which implies encryption (on that connection) being not secure. Which is wrong. What happens on the site itself is a layer above.

>Which implies encryption (on that connection) being not secure. Which is wrong.

No it is not wrong, even your confusingly worded sentence there is still fully correct.

Security (or encryption, or any other synonym you can come up with here) is made up of 3 (well technically 4) parts:

* confidentiality

* integrity

* authenticity

* (and technically non-repudiation, but that doesn't really apply here)

self-signed HTTPS certificates only provides 2 of the 3 (confidentiality and integrity) and it's that last one that is most important (authenticity), because without it you don't know who you are talking to. It could be your website, or it could be some asshole down the street pretending to be your website, you have literally no idea.

You say it's misleading, but it is you that is misreading and misunderstanding the concepts. Encryption without authentication is like encryption without a password. Utterly pointless.

The browser is implying that AES on that connection is unsecure. A better would be "might be unsecure". Because even if it's self signed, there is a possibility it's still the correct certificate.

Yes, because AES in that configuration IS INSECURE!

Just like my analogy, AES encryption with a password of nothing is "unsecure", and no matter how much you try to argue that it's still perfectly secure, you are wrong..

Just like this, the AES is pointless when ANYONE can set the password (or in more correct terms, when anyone can create one with the user in a DHKE). If you can't tell that the server you are talking to is actually the server you meant, then AES does fuckall, because the man-in-the-middle is the one that is setting the password!

You are doing the equivalent of telling me how secure your new house door lock is, while wiring it up to always unlock when someone rings the doorbell... All the security in the world won't help you when you give everyone a way to bypass it instantly.

But maybe I can tell? If I installed the self signed cert, I know it is still secure.

Only if you verify that it is the same cert before you visit the page.

Luckily browsers will show you the warning saying that page is insecure, and give you the option of going there anyway after you have validated that the cert is the same.

Only if you use a shitty ISP which tries to MITM you.

So don’t use a shitty ISP that tries to MITM you.

Problem solved. How is that even controversial?

But it's not only if you use a shitty ISP. It's if any hop between you and the server is being shitty. And only 1 or 2 of those can you control as the user.

Users often have very little choice when it comes to their ISP. Regional ISP monopolies are very much a thing in many countries.

Having spent four months in a hospital, it isn't just "ISPs" who are the problem.

Rather than the hospital supplying any kind of proper authentication, they MITM the first connection to their WiFi, and logged your IP address as your user. They also required you refresh that connection every half hour or so.

There are a lot of people doing things in really bad ways.

We can't fix all of them, and often we don't have a choice about interacting with them.

Yep. That's why the name for any one of these is "captive portal".

Reply on news.ycombinator.com