Hacker News Reader

Comment by crankylinuxuser | Hacker News Reader

I disagree.

Ive seen HSTS applied to things like Windows 10 updates, to prevent users from seeing what exactly your OS is sending to the mothership.

Ideally, we should be able to see exactly the content being exfiltrated, and choose to allow/disallow. But the moment we use tools like ettercap or mitmssl, it kills the session and we can't see the data.

HSTS seems more "self cutting" than useful at this juncture.

View on HN

You're thinking of HPKP and other certificate and key-pinning implementations. HSTS only enforces HTTPS, it does not prevent the usage of things like mitmproxy with custom roots added to your trust store.

If its truly your OS I think you can read all the network data you want to, including the key negotiation. Albeit its not the easiest thing to do.

The use of HSTS is a way to suggest to your clients that they use SSL for that domain - for all requests within a time span (which could be "forever").

If anything, the vendors you mention should be applauded for taking that step towards a more secure distribution of updates. Not enforcing SSL makes malware injection through updates way way easier.

Debian introduced HTTPS repos a while back as an option, but not by default. Other distros already offer it.

Debian, and most other distributions as well, verifies its updates for ages and doesn't need SSL to do that. There are some arguments for using HTTPS anyway, but preventing malware injection isn't one (unless your package manager is exploitable).

It's called defense in depth.

Otherwise go ahead and disable DEP, ASLR, and other modern defense in depth and mitigations mechanisms used by Debian, of course, unless your OS is exploitable.

Reply on news.ycombinator.com