Hacker News Reader

Comment by shp0ngle | Hacker News Reader

what is missing here - localhost is a trusted origin for at least 5 years. You can call localhost without https from all major browsers now without any cross-origin warnings.

so this is all doubly stupid.

View on HN

Note: I am the author of this article.

Yes, that’s what I also assume. I didn’t bother verifying however that mixed content warnings are generally not an issue with localhost in any browser that South Korea cares about (e.g. Internet cough Explorer). Keep in mind that they have some rather adventurous ways to access the local web server, such as JSONP or communicating by posting to a frame.

The localhost issue is very interesting. Of course, there's no chance that someone is impersonating localhost, but there is a chance that someone is eavesdropping on it (although this implies a level of privilege that may make encryption moot). Should browsers just accept self-signed certs for localhost on the assumption that you can't actually impersonate it? Maybe. I used to run internal PKI for a large company and "can I get a cert for localhost" was one of the top 3 arguments I used to find myself in (for the record, the answer was always no).

Interception of localhost traffic is in fact a non-issue, someone able to do it can do worse. So TLS really shouldn’t be necessary on localhost, that’s it.

Certainly seems likely to be the case, but I'm open to there being a theoretical attack that involves being able to inspect the data flowing through the TCP stack without being able to inspect the process spaces of the two endpoints. E.g. if the TCP stack was able to be put in a debug mode that was logging packets somewhere, you'd prefer those to be encrypted. It's pretty far-fetched in terms of an attack surface, but "this data never exists unencrypted outside these two processes' memory spaces" is objectively stronger in a specific way than plaintext transiting kernel buffers.

the browsers are currently just accepting http on localhost and it’s the best solution.

The eavesdropping issue is nonsense.

The only reason is “we want to support IE7”, I guess. Which I didn’t consider but might be an actual usecase in South Korea

Yeah IE7 doesn’t support SSL-less localhost.

I think that will be the main reason.

all major browsers except, iirc, safari. though these apps might not target mac anyway?

Reply on news.ycombinator.com