Hacker News Reader

Comment by mynameisvlad | Hacker News Reader

So I've heard this argument countless times, and it completely makes sense from a theoretical perspective. Yes, it's very possible for MitM to happen, and that would cause one of the two scenarios you described.

But how likely is it to actually happen? For the former, someone would need to target both you and specifically the person who you think will view your resume, and that's, let's be honest, completely unlikely for most people. The second case I can see happening more in theory as it's less discriminating, but does it actually happen often enough in real life to the point where it's a real concern?

FWIW, I have HTTPS on all my websites (because, as everyone mentioned already, it's dead simple to add) including personal and internal, but I still question the probability of an attack on any of them actually happening.

View on HN

I have been MitM'd by my ISP, Comcast, multiple times. Their injection only works on HTTP without TLS.

Sure, I've heard of the Xfinity MitMs which IIRC tracked users in some way. But would that realistically cause any "professional detriment" as expressed by the parent comment? Most users wouldn't even notice it's happening.

Basically, I see it this way:

- You can be MitMed broadly, like the Xfinity case, but the company in question can't really do anything crazy like inject viruses or do something that would cause the user to actually notice because then their ass is going to be on the line when it's exposed that Comcast installed viruses on millions of computers or stole everyone's data.

- Or you can be MitMed specifically, which will cause professional detriment, but would require someone to specifically target you and your users. And I don't see this as that likely for the average Joe.

Really, what I would like to know is: How realistic is it that I, as a site owner, will be adversely affected by the MitM that could theoretically happen to my users on HTTP?

As less and less content is served over HTTP, it becomes more and more realistic for an attacker to simply inject their garbage into every unencrypted connection that has a browser user agent in it.

Consider the websites you view every day.. most of them are probably HTTPS by now.

It's the wild west, basically. Regardless of how likely it is that someone is waiting for you to hit a HTTP site right now so they can screw with it, why even take that risk when the alternative is so easy?

> As less and less content is served over HTTP, it becomes more and more realistic for an attacker to simply inject their garbage into every unencrypted connection that has a browser user agent in it.

I've already covered the general case above. Anyone in a position to intercept HTTP communications like that (into every unencrypted connection) is in a position where if they intercept and do enough to materially harm me or my users through their act, then they will likely be discovered and the world will turn against them. They have far more to lose than to gain by doing something actively malicious that can be perceived by the user. So I don't realistically see it happening.

> Regardless of how likely it is that someone is waiting for you to hit a HTTP site right now so they can screw with it, why even take that risk when the alternative is so easy?

I already said I use HTTPS, so your advice isn't really warranted. I also specifically asked how likely it is, so you can't just "regardless" it away. I get that there's a theoretical risk, and I've already addressed it. But as a thought experiment, it is helpful to know how realistic the threat actually is. So far, I haven't really been convinced it actually is anything other than a theoretical attack vector.

You are making it sound like "injecting random garbage into HTTP" is some new hotness. It have been done since forever. By the way, — email still works that way. But Google and a couple of other corporations would not like you to trample their email-harvesting business, so there is disproportionately less FUD and fear-mongering being spread around email connections.

Internet providers have been injecting ads into websites for years. Hackers and government have been doing same to executables and other forms of unprotected payload.

Hashes, cryptographic signatures, executables signing, Content-Security-Policy, sub-resource integrity — numerous specifications have been created to address integrity of web. There is no indication, that those specifications failed (and in fact, they remain useful even after widespread adoption of HTTPS).

For the most part, integrity of modern web communication is already controlled even in absence of SSL. The only missing piece is somehow verifying integrity of initial HTML page.

Reply on news.ycombinator.com