Hacker News new | ask | show | jobs
by superdisk 2050 days ago
The NSA can see what pages you read, and men in the middle can modify the page to insert malicious JS or ads or whatever without HTTPS.
4 comments

Ok - next question then: why do browsers block self-signed certs? If Lets Encrypt now allows any domain to get a cert, what's the harm in a self-signed cert? Seems like a step up from plain HTTP.
What you are trusting, when you trust a CA, is that it will only issue a certificate for a domain to someone it has verified as the owner. A self-signed cert could be from a man in the middle attacker.

An active MITM is a relatively more exotic threat than a passive observer. In the days when certificates cost money, there was a legitimate argument that you shouldn't need the whole elaborate active-MITM defense just to get protection against passive snooping. But now that you can get both for free... just use Let's Encrypt.

Small nit, verification is only meant to prove control over the domain, not ownership.
The theory here is a self-signed cert could be from anyone (including the NSA) and you wouldn't know. Unless you explicitly trusted the certificate you were using, like enterprises do.
NSA can probably already issue certs from some of the widely-trusted roots. If someone as big as NSA wanted to MITM you, you wouldn't notice...
I feel like this is an oversight due to the path we took to arrive here. HTTP website: no warning, "insecure" mark in the URL bar. Trusted HTTPS website: no warning, "secure" mark in the URL bar. Untrusted HTTPS website: impossible to open in modern browsers by normal users. Really, a non-expired, otherwise-valid self-signed certificate should be treated the same as an HTTP website is. But since LetsEncrypt made self-signed certificates much less common, I doubt there's going to be energy put into improving the experience with them.
As well as the affirmatively "insecure" marking in the URL bar for unencrypted HTTP, it's not a Secure Context (except localhost) and so modern browsers don't offer any new features for this case.

If you're writing an HTML 4.0 web page that's no issue. If you were building a video chat, or you were going to add geolocation to your "Where's my closest store?" page or you want to send Notifications, or you've got a framework that needs Service Workers, those APIs are Secure Context only and won't exist.

The general rule of thumb is, if you could polyfill it, then it's available even without Secure Context, otherwise you need Secure Context to get the new feature. Some older features are being retrospectively given this treatment.

An MITM attack on an HTTPS connection looks exactly like an untrusted HTTPS connection, and the main purpose of HTTPS is to prevent a MITM. The browser should rightly scream louder here than it does for an unsecure HTTP connection.
The man-in-the-middle can self-sign their own certs and present it to you as the site's own self-signed cert. Unless you have some way to verify self-signed certs out-of-band, they're useless.
They’re not useless. They stop passive adversaries, like the Australian government. They just don’t stop active adversaries.

Browser security warnings imply https > http > self signed https. The correct order of should be https > self signed https > http.

We're getting there, HTTP is going to be marked as insecure in the future as well. It's just the massive amount of HTTP sites that couldn't get marked as insecure before, due to the then resulting warning fatigue in users.
Allowing untrusted certificates for https, and showing just a warning for them, would make it impossible for websites to ensure that their traffic is not intercepted
Interesting point. BTW I love your blog and your work on ShareJS :)
To be fair, they probably can anyways, since the site willingly handed over their keys to Cloudflare, or rely on some Google CDN, host on EC2, etc.

It’s the second or third tier nation state actors that you can really make a difference with.

The NSA can still see that just via the metadata of me making the connections necessary to load the encrypted page contents.
If they are focused on you then they can probably do that although it may take considerable work, such as spidering an entire web site to correlate resources on the site against timing and size information.

Without encryption we know the NSA takes the approach of just bulk collecting everything they can to filter after the fact.

So rather than an assigned agent trying to discern what Public Enemy #1 Lammy is up to right now, and painstakingly concluding you have probably just read a Wikipedia article about Jaffa cakes, if you don't have encryption what happens is that the automation notes "Lammy looked at http://en.wikipedia.org/wiki/Jaffa_Cakes" as you click and it goes into the vast heap of stuff snooped that second even though you aren't under any suspicion and it's probably irrelevant.

This bulk surveillance is an unjustified attack on everybody's privacy.

As a site owner that is somehow not my problem. It's not my fault that you have a shitty ISP. I can understand and support that argument.

I do TLS only for my stuff however.

> It's not my fault that you have a shitty ISP.

Really don't think you're grasping this and lack an understanding of packet routing.

Please type:

  traceroute apache.org
It's not just your ISP that's potentially shitty, it's every single hop on that list. Even worse if the person is using an open wifi connection.

Apache will happily serve you an insecure connection, they are the 80th top site on the internet. This type of stuff should be called out by technologists and it's incredibly disappointing when its handwaved away.

That is still not my problem as a site owner.