Hacker News Reader

Comment by w_t_payne | Hacker News Reader

I thought HTTPS was supposed to prevent this sort of man in the middle attack? (Or at least make it harder) -- and I thought that most websites used HTTPS these days...

or am I misunderstanding?

If they are able to do this, and are injecting JavaScript for something as low-return as online ads, then what is to prevent them from changing the news headlines on <insert your news website of choice here>, or the stock ticker feed... How do we know that they aren't?

Do we, as a community, have any mechanism to detect if these sorts of attacks are occurring?

View on HN

The injection is currently for non-HTTPS only, but I can easily see this situation evolving for the worse as HTTPS becomes increasingly the default.

What will happen is someone at Comcast will notice that their injections aren't happening often enough anymore due to HTTPS adoption. Someone at Comcast will suggest implementing a MITM TLS proxy service to get things working again. Someone else at Comcast will note that wouldn't actually work because they can't install fake root certs on every client device...

Then Comcast will basically switch to a model where the HTTPS interception is "optional" (requiring the client-side use the proxy explicitly), but they'll start shipping some kind of "Comcast Setup" executable (or mobile app) users are supposed to run on their client laptops/phones so that they can get these important service notices, which turns on the client-side use of the proxy and installs the fake root certs. Geeks may not install it, but the bulk of their customers will, and everyone loses. I don't think broadband consumers are aware of the fact that they shouldn't trust software provided by their ISP...

Chrome and all other browsers would quickly put an end to that.

> The injection is currently for non-HTTPS only, but I can easily see this situation evolving for the worse as HTTPS becomes increasingly the default.

That's my fear too. This has to be handled by other means and has to stop. If everything is HTTPS you can be sure it gets very unsecure by design, as everyone will upgrade its capabilities and inject you certs, than we would need a new more secure protocol.

Why is email still unsecure and sent in plain text? Why is there hype for HTTPS but everyone is fine with sending mail in plain text yet we have SMIME, etc and no one is using or supporting it.

As the other comment said, HTTPS does prevent this, and this only happens on HTTP pages.

> Do we, as a community, have any mechanism to detect if these sorts of attacks are occurring?

Yes, Caddy can detect whether a connection is being MITM'ed: https://caddyserver.com/docs/mitm-detection

As that page describes, Caddy's detection only works on SSL-served pages, by comparing the TLS Handshake, to the expected TLS Handshake pattern of the advertised User-Agent.

Ironically, if you're using Caddy, I struggle to think why you wouldn't already be pure HTTPS.

Yes, and it is fair to assume that a page served over HTTP is not trustworthy in any case.

Yup, but "these attacks" in your first post was specifically HTTP modification, which is the only thing Comcast is capable of doing.

HTTPS does prevent this. This can only be injected on non-secure connections.

Use HTTPSEverywhere on your browsers, and then enjoy the "You're close to your monthly limit!" pop-up on the Steam Store!

What?

I think the intent was to comment that extensions don't protect programs with embedded web views, like the steam store. I'd hope the steam store is using https though...

Only on checkout pages. For the rest of the storefront they actually redirect you from HTTPS to HTTP.

That's especially bad, because you can't actually see the origin or whether TLS is in use from the store's interface...

Um, I assume the code for that pop-up is rendered into the page on the web server that produced the page, before being returned to the browser.

That is precisely the problem. If the notification were rendered as part of the page by the web server, no one would have issue with it (though it would likely be blocked by adblockers anyway).

It's the fact that the ISP is modifying traffic in-route, to inject something that was never intended to be part of the page, that is the problem.

I expect my ISP to be a neutral carrier of messages, not meddling and altering my mail to add whatever they happen to feel like adding today.

Assuming Comcast adheres to their RFC[1], this injection method would only affect unsecure HTTP per general requirement R3.1.2.

[1] https://tools.ietf.org/html/rfc6108#section-3.1

A VPN will prevent this.

I'm curious if there's a way to hash your code, so... I guess this can be overwritten as well. But like a check sum to make sure your client code is the same as you made it.

HTTPs is good, got it.

Subresource integrity checking. Most CDNs provide <script> tags with these hashes.

Thanks I will look into that.

But the MITM can just remove/change those hashes.

Yes, if the index.html is not HTTPS or otherwise compromised.

Reply on news.ycombinator.com