4 ms·
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 eavesdropp
by heleninboodler 4y ago
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).
- palant 4y agoInterception 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.
- heleninboodler 4y agoCertainly 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.
- shp0ngle 4y agothe 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