HTTPS is worse than security theater | Hacker News Reader

HTTPS is worse than security theater

medium.com

5 pointsdfv8 comments

The author ignores the "secure" flags on cookies for some reason. This is a standard in pretty much all frameworks now. Most of their ideas of automatic mitm will not work, because the victim will not be logged in on the http connection.

Not sure what you're talking about. The autofill thing still works, because you don't need to be logged in for that. The Stripe thing would work if you managed to login via the HTTP website, or the website didn't require you to login to make payments. Not all places uses web frameworks - Synack doesn't use Secure cookies for authentication purposes.

You're making pretty strong claims in the post:

> You decide to visit (or your browser polls on your behalf) ANY website that either: ...

> ... I get these accounts transparently, almost as soon as the page loads.

So on the point of accounts... yeah, in badly done websites which still don't use httponly and secure attributes on cookies, you'd be able to do that. And that's totally on the developers - this protection was there for ages. This applies whether you use a framework or not, I only mentioned them to show the popularity of the solution. Since Firesheep this is table stakes.

> Suppose I have MITM’d the actual page, but a remotely sourced javascript file — Stripe’s, for instance

Go ahead and try it. Stripe scripts refuse to work from sites loaded over http to prevent this scenario.

Autofill - that's effectively closed. Chrome won't autofill logins on HTTP sites anymore since v86.

I agree there are broken websites out there, but it's not even close to https being a security theatre.

Added later: I'm not sure I understand the persistence claim either. The initial request is never pulled directly from the cache, and the official page will not reference the http version of JavaScript files. Even if you have the http version cached forever, it's the https ones that will be pulled later.

I'm in the middle of developing killginx, which will perform some of these attacks, so I'll just link them here when I'm done. You're definitely wrong about Stripe being invulnerable to this sort of thing, and half wrong about the other things. Up-to-date Firefox and Chrome are not the only things that autofill or negotiate http connections.

> Up-to-date Firefox and Chrome are not the only things that autofill or negotiate http connections.

Sure. But it basically means it's a matter of time before everything else stops doing it too.

I've just tried to use the stripe checkout js from an HTTP site and it doesn't work. You can send your own requests of course, so I wonder if that's what you meant instead... (To be clear, I didn't say stripe is not vulnerable, just that you can't use their scripts as they are now - so simple id swapping wouldn't work)

Either way, I'm curious to see killginx.

Loading javascript from another domain is deliberately not observable, so for it to have vulnerabilities stripe would have to be putting user data in javascript responses, which seems unlikely.

Given the article is deleted I don't know what points the author was making, but if you have found a way to convince stripe (or anyone else) to transmit user data in scripts you should probably report that. I don't know if they have a bug bounty program.

and it's been deleted.

I'm guessing from the other comments here the content was not particularly accurate.

I honestly hope the killginx will show us some cool ideas. I think the article took the opinion from the title too far, but it did raise some valid issues for websites which don't use all available protection. Specifically that if you don't use hsts, permanent redirection, secure cookies, etc. you are exposed to mitm abuse. It's not novel on its own, but it would be great to see practical applications which that post lacked.

Reply on news.ycombinator.com